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

Robert Corbett robert.corbett
Fri Oct 12 19:22:54 EDT 2012


On 10/09/12 19:25, Malcolm Cohen wrote:
>
> 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.
>

Rafix Zurob's proposal in meeting 199 was similar to this proposal.  The problem 
we identified then was that the change made in Fortran 2008 has been integrated 
into the standard in more than one place.  For example, in Fortran 2003, the 
statement

       P => Q + 1

where the operation Q + 1 returns a pointer to a data object is permitted.  If 
only the change suggested is made, that statement will not be permitted in 
Fortran 2008.  There are decisions that will have to be made regarding the 
ASSOCIATE and SELECT TYPE statements.

Robert Corbett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20121012/9b38e218/attachment.html 



More information about the J3 mailing list