robin wrote:
...
>>>> 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.
>>>
>>> 'false' precedes 'true' in the dictionary.
>>
>> "Zero" preceeds "one" as well.  Mention something relevant to
>> the discussion.
>
> You have difficulty focussing on the discussion at hand.
> You bring up irrelevant references to SCAN and VERIFY
> which are for string handling.

The relevance is that I would recommend that SCAN and VERIFY
be allowed to apply to other data types is a consistent way.  Your
reference to the dictionary is *completely* irrelevant in that you
obviously *DO NOT* want to apply results from it in any consistent
way.

>> The fact that PL/I does something is irrelevant to Fortran.
>
> It might give you an insight into the way in which Fortran
> could be improved.

As a counter-example perhaps.

>>>> 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.
>
> Perhaps, if he were interested in vectors.
> However, what he wanted was the occurrence of the first true,
> hence he would prefer MAXLOC, as this gives both row and
> column (of matrix), or three values in the case of a 3-D array.
> In other words, neither SCAN nor VERIFY is useful,
> as they don't deal with the general case.

They deal with it better than MAXLOC since LOGICALs *CORRECTLY*
are not an ordered data type.  And, who said the extensions of SCAN and
VERIFY wouldn't be extended to handle arrays of greater than rank
one?  I didn't.

> You're saying that a simple hand-coded loop is not legible?
> What difficulty do you have comprehending
> do i = 1, n
>     if (b(i)) return
> end   ?

Well, for one thing, *you* had difficulty reading it well enough
to know that the appropriate keyword to exit a loop is EXIT.
RETURN will exit the present procedure.  Or, are you actually
admitting that I was right after all, and the search *should* be
written as a procedure to be called rather than an embedded
loop at each use?

And, show me again where it's vital that .true. be greater than
.false.  I don't see that dependence in your loop.  Yet that's
persistent gist of your diatribes.

>>  I suspect that's
>> your usual style.  Some more legible procedure call would be
>> better.  Making it an intrinsic would be better still (no possible
>> misinterpretation of varying implementations).
>
> "Misinterpretation of varying implementations" is the core of
> the problem with the internal representation of logicals.

Only if non-standard and nonsensical operations are permitted.
Comparing LOGICALs for anything other than .EQV. or .NEQV.
doesn't make sense (and isn't permitted in the standard - correctly).
Given that programs don't violate the standard, it makes no difference
what the internal representations of .true. and .false. are.

>>  Massive
>> proliferations of intrinsics is an issue too.  But, since there
>> already are intrinsics with the proper definitions, though
>> presently restricted to CHARACTER data type, I believe
>> the proper choice to be to remove that restriction.
>
> Your suggestions to change SCAN and VERIFY lacks credence,
> as they don't handle the general case.

No, your loop doesn't handle the general case.  Your loop assumed
the B variable was rank one.  SCAN and VERIFY could easily handle
the general case.  When did I say they wouldn't?

--
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