Harvey Richardson wrote:
>
> > Steve Schlaifer wrote:
> > >
> > > In message <[log in to unmask]>, [log in to unmask] writ
> > > es:
> > > > Because many programmers expect short circuiting behavior for .AND., leading
> > > > to erroneous code that usually works,
>
> Surely not, I would have thought that those programmers clever enough
> to know that short circuit behaviour exists in a given language will
> not assume it of other languages.

I once held exactly that view. However, as I encounter more and
more scientific and engineering applications programmers who are
learning Fortran as a second language after C, and/or C++, I have
adjusted my view.

They have learned a certain view of the world that has a certain
kind of internal consistancy and logic, and they cannot help
making the sorts of assumptions that fit that world view and that
sense of logic. They expect boolean-valued operations to be as
consistant across languages as numeric operations. Perhaps they
expect such operations to be even more consistant, since booleans
are simpler than numbers, more discrete, and more universal across
computers.


> > > > and because the current syntax for
> > > > specifying short circuiting, i.e.,
> > > >
> > > > IF (K .GT. 0) THEN
> > > > IF (X(K) .GT. 0.) THEN
> > > > . . .
> > > >
> > > > can lead to duplicated code if an ELSE branch is required,
>
> Why?

Will a code template suffice?

Desired code:
if( K > 0 .short-circuit-and. X(K) > 0 ) then
.... !code for short-circuit true case
else
.... !code for short-circuit false case
end if

Straightforward Fortran 77 code:
if( K > 0 ) then
if( X(K) > 0 ) then
.... !code for short-circuit true case
else
.... !code for short-circuit false case
end if
else
.... !duplicate code for short-circuit false case
end if !^^^^^^^^^ ^^^^


> At least it is immediately understandable.

Immediately "parsable" I would buy. Immediately "understandable"
seems much less likely to me. IMO, The code above is only
"understandable" after you realize that someone (maybe yourself
two years ago?) wrote exact duplicate code for the "false case",
and then only after you realize that he (yourself - 2yrs.?) did
it on purpose.


> > > > I have sometimes
> > > > wished for more direct way to express short circuiting behavior in Fortran.
> > >
> > > Is there something unacceptable about:
>
> [cryptic example 1]
>
> > In the same spirit, what is wrong with this?:
>
> [more cryptic example 2]

If you could detail what you find cryptic in these examples it
would greatly help me in constructing examples like this in the
future.

Steve's example seems particularly straightforward to me, as it
uses simple Fortran 77 syntax. That said, let me take a stab at
demystifying my example a little. I believe I could have made
it more readable by separating out the complicated merge-based
indexing expression:

LFLAG = K > 0
KSAFE = merge( K, 1, LFLAG )
! ^ use "lbound(X, 1)" to be perfectly safe
        IF( LFLAG .AND. X( KSAFE ) > 0 ) THEN
          ...
        ELSE
          ...
        ENDIF


> I get more convinced that it is important to write code that is
> readable, maintainable and less prone to bugs.

To me, Steve's code was as easy to parse ("read") as the code you
seem to prefer. I would be interested in knowing what parts you
thought "cryptic."

My example is not as "immediately parsible" as the code you seem
to prefer, but I find it more maintainable in the following ways:
- It avoids duplicate code for "short-circuit false" case
- It avoids nesting block-IF expressions


> (Of course this
> gets tricky in the pursuit of performance.) I don't think that
> some of these suggestions would help me.

Well-spoken. If you find such code unusable, don't use it;
however, I suspect your criteria are rather subjective. Again,
any insight you can give me into those criteria would be helpful.


> > Something like the proposed ".ANDTHEN." might be useful in more
> > esoteric cases, but this case is really not that hard to handle.
>
> At least call it .SCAND. (Short Circuit AND).

".ANDTHEN." seems more intuitive to me, but that too is highly
subjective. I would settle for any reasonably mnemonic name,
but I must admit, because the most common cases have such trivial
work-arounds, this feature is still not very high on my wishlist.


-------- Cray Research --------- Roger Glover
-- A Silicon Graphics Company -- http://home.cray.com/~glover


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%