J3/06-359

Date: 3 November 2006
To: J3
From: Dick Hendrickson
Subject: Clause 13 Integrating BITS with LOGICAL
References: J3/06-007R1

I believe we need to do something to the LOGICAL function when
it has a bits argument. The current situation "it's processor
dependent", is way too vague. If you read comp.lang.fortran
for a few days, you'll discover that many people assume that
true and false are one of:

1) one and zero
2) non-zero and zero
3) minus and plus
4) all ones and zero

and they believe that to the very core of their being. Giving
them a function to convert bits to logical without telling
them how it works is a recipe for disaster.

It's especially misleading when all of the bit-ish truth tables
use 1 for true and 0 for false, at least by implication.

At least with integers, there is essentially only one way to represent
them on modern chips. Ditto with reals, IEEE is almost ubiquitous.
And people who are taking apart a floating point number really expect
it to be hardware dependent. So, INT and REAL are reasonable and almost
always will do the right thing with bits.

If people want uncertainty about how to convert bits to logical,
let them use TRANSFER.

Proposal 1. Remove the "or bits" from the allowed types for
the LOGICAL function [397:16] and reword the
natter below.

Proposal 2. Specify how things get converted. If the lower bit
is 1, it's true, else false. This is a common
expectation and fits in reasonable well with how
the bits functions do things (with kind = 1).

Proposal 2A As above, limit L to bits kind = 1


Proposal 3 If we don't do proposal 1, allow a bits kind entity
as the MASK in essentially all of the functions that
have a MASK argument. If we allow any kind of intrinsic
transformation between bits and logical, then people
can do SUM (array, MASK = LOGICAL(bits_entity)).
It seems silly to not let them do
SUM(array, bits_entity)

Yes, proposal 3 is feature creep. But, it is highly justifiable!