operator precedence in Fortran 2008 draft

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

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.

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.

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.

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)

Furthermore, negated powers should be allowed without
parentheses. And the expression

X**-Y*Z

should mean

(X**(-Y))*Z

not

X**((-Y)*Z)

There are existing Fortran implementations which treat
the power operator as a left associative operator 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.

Bob Corbett

.

Relevant Pages

  • Re: F95 standard
    ... I would recommend the latest draft of the fortran 95 standard: ... ISO messed up the pdf links in f2003. ...
    (comp.lang.fortran)
  • Re: precedence of operations
    ... I don't think any standard for Fortran used ... In the more recent versions of the standard, ... signs are described as having slightly higher precedence ... have higher precedence than the corresponding infix operators. ...
    (comp.lang.fortran)
  • Re: fortran standard
    ... available for poor people. ... That is the last draft of the Fortran 2003 standard. ...
    (comp.lang.fortran)
  • Re: saveing allocatable components of derived types
    ... Fortran 95 standard, though they are allowed in Fortran 2003. ... extension to the F95 standard -- introduced the allocatable derived-type component functionality that now appears in the F2003 standard. ... Incidentally, is there a draft version of this TR available online, as the draft versions of the F95 and F2003 standards are? ...
    (comp.lang.fortran)
  • Re: fortran standard
    ... available for poor people. ... That is the last draft of the Fortran 2003 standard. ...
    (comp.lang.fortran)