Re: Shortcut logicals (was: Re: F200x )

["James Giles" <jamesgiles@worldnet.att.net>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3878 bytes --]

James Van Buskirk wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:mXzLd.100$xR1.94@bgtnsc04-news.ops.worldnet.att.net...
>
>> Well, I have the F2003 FCD open right now, in �7.4.3 Masked array
>> assignment - WHERE.  So, perhaps you can point out what part of
>> it resolves the issue I raised:
>
>>    cond1 .and. cond2 .andthen. cond3 .and. cond4
>
>> Is COND4 permitted to be evaluated or not?  I don't see that
>> WHERE tells me.  It has a concept of "pending control" which
>> I see can be applied on nested constructs, but in the above
>> expression, not of the terms actually present are part of any
>> "pending" condition.  Or, are you talking about some other
>> aspect of WHERE entirely?
>
> OK, I have added comp.lang.ada, so hopefully someone there
> can answer the question about the effect of precedence on
> your snippet, and also discuss the ergonomics of Ada short-
> circuiting logical operators, or whatever they call them.
>
> I would answer your question above, assuming cond1 .AND. cond2
> evaluate to scaler .FALSE._lk to be that it all depends; either
> cond3 or cond4 or neither or both could be 'short-circuited'.

But, that's just the problem.  The whole purpose of the separate
short-circuit operators is to eliminate ambiguities about whether
a given condition is evaluated.  That allows the programmer
to prevent evaluation of conditions if such evaluation would cause
exceptions or program termination.

Merely saying "it depends" doesn't help.  But, making a different
rule - that the new operators are lower precedence than the non-shortcut
ones, for example - does help.  That makes the example unambiguous.

The standard permits logical operators (and their operands) to be
evaluated in any order that produces a logically equivalent result.
Presumably that would be changed with respect to the shortcut
operators to require the right operand be evaluated conditionally
based on the value of the left.  In the example in question, assuming
that the operators all have the same precedence, the actual order
of evaluation might be pretty much anything.  COND1, COND2,
and COND4 might all be ecaluated before any of the operators
are done at all.  So, the expression might be as if it were rewritten
as either of (as well as others):

       cond4 .and. cond1 .and. cond2 .andthen. cond3
       cond2 .andthen. cond3 .and. cond4 .and. cond1

In fact, the only requires order (as far as I can tell) is that COND3
can't be evaluated before COND2 is found to be .true.  (If COND2
is array valued, the elements of COND3 corresponding to those
elements of COND2 that were .true. would also *may* have to be
evaluated.  I can see that in this case only an analogy to how WHERE
works is appropriate.) But this is the same result as if the shortcut
operator had lower precedence than the non-shortcut operator.

Now consider:

   cond1 .or. cond2 .andthen. cond3 .or. cond4

Even given that .andthen. has higher precedence than .or., the
rules of Fortran still suggest that COND1, COND2, and COND3
might all be evaluated before the .andthen. operator is executed.
After all, reordering the .or. operator is still permitted.  Both the
following are allowed interpretations as well as others):

   cond4 .or. cond1 .or. cond2 .andthen. cond3
   cond2 .andthen. cond3 .or. cond4 .or. cond1

Now, not only do I find this confusing, I'm sure it will hide latent
errors in the code of others.  Requiring parentheses or using a
function-call notation eliminates all ambiguities.  Making the new
operators lower precedence than everything else helps a little.

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