(j3.2006) (SC22WG5.5349) RE: J3 Fortran interp letter ballot #31revised - due 6-Oct-2014
Sun Oct 5 21:00:50 EDT 2014
>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
[399:17] 22.214.171.124 LOCK_TYPE, C1302
"variable of type LOCK TYPE"
-> "variable with declared type LOCK_TYPE".
"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.
............................Malcolm (typhoon) Cohen.
More information about the J3