Re: operator precedence in Fortran 2008 draft

robert.corbett@xxxxxxx wrote:
The current draft proposed standard for Fortran 2008
has added a new type BITS. The logical operators
.AND., .OR., .EQV., and .NEQV. have been overloaded
to take operands of type BITS. I believe the intent was
to overload the relational operators as well, although
the current version of Table 7.1 doesn't show it.

Presumably you mean only .eq. and .ne. BIT is not
an ordered type (as far as I know).

By reusing the operators in this way, the current draft
needlessly repeats what many people considered a
mistake in the design of the C programming language
30 years ago.

Well, the main problem with C is that it doesn't have a
logical data type. Hence, results of comparisons can
be used further as operands to additional comparisons
or arithmetic operations. Even with BIT, Fortran still
has a LOGICAL data type. Results of comparisons
should not be subsequently allowed as operands of BIT
or arithmetic operations.

Consider the expression

X .AND. MASK .EQ. FLAG

where X, MASK, and FLAG are of type BITS. The
expression will be grouped as

X .AND. (MASK .EQ. FLAG)

which will usually result in a compile-time error.
Thus, the operator precedence chosen by standard
forces the use of parentheses in the common cases.

How is that a problem? I find most code more legible
if complicated logical expressions are parenthesized
in this manner anyway. And, I oppose the mixed-mode
application of .AND. as well. I don't think it should
be legal. Is it applied bit-wise with whatever the
internal representation of the LOGICAL result is
assumed to be? Or is .eq. supposed (by you, since
the proposal still doesn't list it) to be a bit-wise
compare?

An alternative would be to add new operators for the
type BITS. The operators .BAND,, .BOR,, and .BXOR.
have been used for bitwise operators on integer values
in some Fortran implementations. They seem well
suited for use with bits values as well. The new
operators would have higher precedence than the
relational operators. Using the new operators has the
advantage of removing possible confusion between
the logical and bitwise operators.

But, type resolution already removes that confusion. Unless
you are planning to further overload the operators so that
mixed mode between LOGICAL and BIT (or worse, INTEGER)
is permitted I still don't see the need for yet more operators.
That's the second mistake of the C design: more than one set of
operators for the "and" and "or" operations. People that use C
only infrequently are always getting them confused.

One side issue is deciding what the precedence of the
operator .BXOR. should be relative to the operator .BOR.
The C standard gives its exclusive or operator higher
precedence than its inclusive or operator. I feel that
it would be preferable for the two or operators to have
the same precedence, but I don't feel strongly about it.

I agree there, but with the caveat that they shouldn't be
associative with each other. That is (whatever the operators
are called):

X "or" Y "or" Z
and
A"xor" Y "xor" Z

These should be permitted (both operations are associative
and commutative anyway - even computationally). But:

X "or" Y "xor" Z

This should not be permitted. The programmer should be
required to parenthesize. (Dijkstra mentions the same situation
for logical AND and OR. He thought they should have the
same precedence but not associate with each other.)

All this is assuming that operators for these operations are
desirable in the first place. I'm not convinced that's true.
Function-call syntax might be better all around. And, I remain
opposed to the BIT feature anyway.

Another issue with operators in the current Fortran 2008
draft is that it is long past time for Fortran to allow
the power operator ** to be used as a right associative
operator. The expression

X**Y**Z

should be allowed and should be interpreted as

X**(Y**Z)

That's been the case at least since F77 (ANSI X3.9 1978,
p. 6-3, lines 27-44). In F90 and since, the syntax rules
make it clear that exponentiation is *parsed* as a right
associative operator and the standard(s) do clearly state
the the *meaning* of the expression is established by
those syntax rules. So right associative use of exponentiation
has always been the rule.

Furthermore, negated powers should be allowed without
parentheses. [...]

I disagree. I believe the parenthesis should remain required.

X**-Y*Z

should mean

(X**(-Y))*Z

Of course, X**(-Y)*Z is already the same as above since
** has higher precedence than *. Of course, it's even clearer
as Z*X**(-Y). Multiply is still commutative.

not

X**((-Y)*Z)

I agree that's appalling.

There are existing Fortran implementations which treat
the power operator as a left associative operator [...]

If so, they are not conforming (and haven't been since
practically forever).

[...] and
that assign the bizarre precedence shown for negated
powers. Those implementations would have problems
dealing with the new rules. Users have problems with
the existing interpretations. I prefer siding with users.

I think users would be happier in the long run if parenthesis
remain required. Requiring a few extra keystrokes inflames
the ire of a few, but even they will actually benefit from the
improved legibility. The really confusing case is:

-A ** B

In my own language that expression is illegal and you have
to parenthesize to clarify what meaning you intend. And even
under the rules you are discussing Fortran will still interpret
that as:

-(A**B)

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


.

Relevant Pages

  • Re: operator precedence in Fortran 2008 draft
    ... as operands of the order relations. ... the operator precedence chosen by standard ... Recall that parentheses in Fortran serve double duty. ...
    (comp.lang.fortran)
  • C/C++ Ambiguity in Order of Evaluation
    ... I have never been able to resolve the issue of order of evaluation in ... precedence and grouping of operators." ... That unary - has the highest precedence or the use of parentheses in - ... about binding operands to operators. ...
    (comp.lang.c)
  • Re: compare a large number of variables
    ... I wouldn't want parentheses to change the behavior of the ... > case where all operands have the value 0.) ... Is "identically as for the single-way equality operator" a sufficient ... > So, if you just add some APL to C, you'd be able to do what you want. ...
    (comp.lang.c)
  • Re: question about pointer
    ... parentheses will somehow force complete evaluation of the increment ... Overriding precedence can sometimes have the effect of ... same - the parens are redundant. ...
    (comp.lang.c)
  • Re: operator precedence with && and comma
    ... >> Precedence is just a way of dsescribing which expressions are ... >> operands to which other expressions. ... >> predicting self-predictors' predictions is predictably unpredictable. ... > So if 'precedence' is different that 'order of evaluation', ...
    (comp.lang.c)
Loading