robin wrote:
...
>> If all you've got is a single bit, that's also the sign bit.
>
> A bit in PL/I is unsigned. That's the definition of a bit.
That's not how I read the PL/I document. The BIT attribute
can only be applied to non-numeric data. I don't remember
how bits compare for relative order, or even if they *can*
be compared for anything but equality or inequality. The
attributes SIGNED and UNSIGNED are not permitted at all
with BITs, as they only apply to numeric data. In any event,
the PL/I definition is irrelevant to the current thread except
for comparison purposes only: this is the *FORTRAN*
newsgroup.
I would still argue that LOGICAL data should be unordered
(that is, concepts like "less than" or "greater than" are not
defined for them). If they *are* ordered, I still prefer .true.
to be less than .false. as the more natural ordering. If you define
LOGICAL as an enumerated type, the most natural declaration
(whatever the syntax) is to list the two values as TRUE and
FALSE in that order. It also, as I already pointed out, permits
the most flexibility in the use and representation of LOGICAL.
Now, as for the original question: I've always said that there
are many "string" operations that should be allowed on data
other than type CHARACTER. Among these are the intrinsic
functions SCAN and VERIFY. If these could be applied to
arrays of LOGICAL, the functionality the original person wanted
would be easy.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
|