(j3.2006) (SC22WG5.4825) [ukfortran] J3/12-nnn J3 interpretations letter ballot #26 after meeting 198 - due 12-Oct-2012

[Malcolm Cohen]

The following Fortran interpretations are being balloted:
 

Yes  No   Number     Title

 

-Y-  ---  F08/0040   MOVE_ALLOC for coarrays

-Y-  ---  F08/0074   Implicit type in BLOCK construct

-N-  ---  F08/0075   Pointer function reference as variable in assignment

-N-  ---  F08/0076   Pointer function reference in READ

-Y-  ---  F08/0077   Function references as variables in DATA statements

-Y-  ---  F08/0078   Are the IEEE values +0 and -0 distinguished

-Y-  ---  F08/0079   NAMELIST and type specification

-Y-  ---  F08/0080   Array constructors with polymorphic values

-Y-  ---  F08/0081   Deallocation error handling

-Y-  ---  F08/0082   Generic identifier and dtv arguments

 

NO vote for F08/0075:

 

(Note that the edit is wrong ? missing ?label? after the second statement ? but that is not the reason for voting NO.)

 

Even though a ?.ADDRESS.? operator might look ?cool?, I have come to the conclusion that allowing operator syntex to denote variables is a mistake.  The standard has various restrictions on operators to reduce the ability to obfuscate your code, e.g. arguments are required to be INTENT(IN).  The purpose of operator syntax was to allow user-defined algebra, not junk coding.

 

There is no functionality provided by this feature that is not adequately served, with less obfuscation, by function reference syntax.

 

The correct fix for this interp is to acknowledge our mistake in permitting this syntax to occur at all anywhere, and changing R602 and C602 to

 

R602 variable is designator or function-reference

 

C602 (R602) function-reference shall have a data pointer result.

 

Note that a less extreme viewpoint would be to allow the operator syntax except as the variable in an assignment statement (or READ statement).  That would be a better solution than the nitpicky syntax tweaks that are the current proposed solutions to this interp and the next, but would not be as consistent as disallowing this problematic syntax entirely.

 

NO vote for F08/0076:

 

This should also be fixed by removing this particular syntax (operators) for the feature (pointer function reference as variable).  Or at the very least, removing it from the READ statement.

 

Cheers,


-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20121010/dd21555c/attachment-0001.html