(j3.2006) READ unit ambiguity
Thu Mar 1 08:39:35 EST 2012
On 3/1/12 3:17 AM, Malcolm Cohen wrote:
>> READ (unit) .op. 666, X
>> The operator .op. has both unary and binary forms. The unary form
>> returns a pointer to a target variable, which the binary form
>> returns a character string of type default character that has the
>> form of a format. He asked if "(unit) .op. 666" should be treated
>> as a format or as an i/o control list followed by a variable.
> Nice one. In Fortran 90-2003 this is standard-conforming: (unit).op.666
> is the unit specifier.
Really? The unit specifier would have to be entirely enclosed in ( ),
read ( (Unit) .op. 666)
according to the syntax rules. Worse, a unit spec would not be followed
by a comma. So, I think f90/f03 would see this as not a unit specifier,
but rather (UNIT).op.666 as a format. If the parser goes down the path
of (UNIT) being the unit specifier, it would hit a problem because
.op.666 was not a valid input-item in f90/f03 (expression, not a variable).
> In Fortran 2008 we have added an ambiguous parse to the statement so by
> clause 1 the program is not conforming.
Assuming that UNIT is a variable or named constant valid for a io-unit,
there is a problem that needs fixing.
I've now lost track of how many times the new "function reference
returning a pointer is a variable" has caused bad side effects in the
standard. "Cool" ideas sometimes seem to have grief / benefit ratio
that are higher than expected.
> That was unlucky. We need to do something, even if that is just adding
> another incompatibility to the list in clause 1. Other fixes are
> possible - e.g. forbidding the first item of an input-list from
> beginning with an operator (this would resolve the ambiguity in favour
> of maintaining backwards compatibility).
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101
More information about the J3