(j3.2006) (SC22WG5.5349) RE: J3 Fortran interp letter ballot #31revised - due 6-Oct-2014

[Malcolm Cohen]

>
>The following Fortran interpretations are being balloted:
>
>Yes  No   Number     Title
>
>-Y-  ---  F08/0108   ultimate components and coarrays
>-C-  ---  F08/0109   LOCK_TYPE and unlimited polymorphic
>-Y-  ---  F08/0112   STAT= and ERRMSG= in ALLOCATE and DEALLOCATE
>-Y-  ---  F08/0113   Specifiers in image control statements
>---  -N-  F08/0114   Can LOCK_TYPE components have the POINTER attribute?

COMMENT for F08/0109:

  Bill Long writes:
    "The example Q3 has a variable, C, of type LOCK_TYPE that
     is not a coarray. This violates C1302.   Answer A3 is wrong."

No, it cannot violate C1302 because that is a syntax constraint.  Only 
things that are statically detectable static properties of the program 
source text can be syntax constraints.  That means that "type" in C1302 can 
only mean "declared type".

C is CLASS(*) so has no declared type and therefore cannot violate C1302.

C1302 ought to be fixed to say "declared type" explicitly, to avoid this 
confusion;

[399:17] 13.8.2.16 LOCK_TYPE, C1302
         "variable of type LOCK TYPE"
         -> "variable with declared type LOCK_TYPE".

Bill continues:
  "For the same reason the example Q4 is defective and answer A4 is wrong. "

For the same reason, there is nothing wrong with Q4.

>The example code in Q5 is also defective, although could be repaired by 
>changing the declaration of X to
>
>       TYPE(LOCK_TYPE),SAVE :: X[*]
>
>That seems to be sufficient to make answer A5 acceptable.

X should certainly be explicitly made a coarray, but giving it SAVE seems 
unnecessary (this might be a main program or module, or might be a 
subprogram with a global SAVE, or X might be a dummy argument).  I guess it 
doesn't hurt though (other than looking a bit strange to have X saved but C 
not, so if we're going to SAVE one we should SAVE the other).

NO VOTE on F08/0114:

This is just the wrong decision.  People use pointers for all kinds of 
reasons, e.g. switching between two different structures, emulating 
optionality, etc.  We allow pointers to be followed cross-image from a 
coarray, which means that pointers with a potential subobject of type 
LOCK_TYPE would indeed be useful in such scenarios.

We should not add this new restriction; rather, we should remove the 
misguided "style preference" that is currently badly expressed by C1302.

Cheers,
-- 
............................Malcolm (typhoon) Cohen.