(j3.2006) [ukfortran] (SC22WG5.4844) J3 interp letter ballot #27 -

[Malcolm Cohen]

The following Fortran interpretations are being balloted:

Yes  No   Number     Title

-Y-  ---  F03/0053   The BIND attribute for C_PTR and C_FUNPTR
-C-  ---  F08/0075   Pointer function reference as variable in assignment
-Y-  ---  F08/0083   Type parameter default expressions allow circular
                               dependence
-Y-  ---  F08/0084   Pointer arguments to PURE functions
-Y-  ---  F08/0085   Problems with PARAMETERs
---  -N-  F08/0086   Implied-shape and separate PARAMETER statement


COMMENT on F08/0075:

This interp as about the syntactic problems caused by F2008's operator syntax 
for "pointer function reference as variable".  It is not about the latter 
changing the semantics of F2003 programs with SELECT TYPE or ASSOCIATE.

I agree with Robert Corbett that on the face of it there is an apparent problem, 
but this needs to be dealt with separately.  As the standard is in F2008 as 
published and as would be after applying the edits in F08/0075, his example is 
technically not conforming as the semantics from clause 8 contradict the 
"upwards compatible" statement in clause 1.  That's not a particularly 
reasonable outcome!  But is not related to whether we can use operator syntax to 
denote a variable.


NO vote on F08/0086:

I agree with Bill Long's comment that the new constraint should replace the old 
constraint.

I agree with Robert Corbett's comment that the second example needs to have its 
unrelated errors removed.

I agree that there is a difficulty with incorrect rank, but disagree that that 
is related to this interp in any way, especially as the purported problems are 
not limited to implied-shape arrays.

I disagree with the comment that ambiguous syntax is just fine and dandy. 
Programs that use ambiguous syntax are not conforming; having ambiguous syntax 
in the standard just makes it less obvious that non-conforming programs are not 
conforming.  If we want to add an <implied-or-assumed-shape> array-spec, let's 
add it, not just pretend that it's there when it is not.  Otherwise someone is 
quite likely not to implement this imaginary extension.

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