(j3.2006) (SC22WG5.5368) J3/14-279: J3 Fortran interp letter ballot #32 revised - due 9-Jan-2015

[Malcolm Cohen]

Bill Long writes:

>For F08/0110:
>-------------
>
>I agree with the intent of the answer, but I think the edits say
>things we don't intend. In particular, "affected by [the] data
>transfer" is too broad.
>
>In the [243:3-5] edit we are saying that the value of the SIZE=
>specifier cannot "be affected by data transfer caused by that
>statement".  This is certainly not true.  The data transfer
>*determines* the value.

It is not affected by the data transfer, it is affected by "what the data is". 
That is a horse of a different colour.  The data transfer is the transfer of the 
data, which comes down to the definition of items in the input-list or (for an 
interrnal output statement) the definition of characters in the internal file.

That is, the input (or output) data determines both the "data transfer" and the 
SIZE= value.  It is not the actual transferring part that determines the SIZE= 
value.  The "data transfer" is a subset of item (6) in 9.6.4.1p2, whereas 
setting SIZE= is item (9).

I guess we could replace "data transfer" by "definition of variables by the 
transfer of the data", but that seems rather excessively verbose (ironic given 
your comment on another interp!).

>The [243:6-7] edit implies that the statement
>
>  read (*,*) I, A(I)
>
>is not conforming, since the denotation of A(I) depends on the value
>of I which certainly is "affected by the data transfer". Yet this sort
>of thing appears all over in existing codes.

That edit DOES NOT SAY THAT.  It says
  "The denotation of a variable that appears in a specifier ... shall not be 
affected...".

An <input-item> is not a specifier.

That is, this will affect things like (the already invalid):

  read (*,*,iostat=i(n)) n

>For F08/0121:
>-------------
>
>The edit says more than is actually true. Not any <defined-operator>
>is allowed in a specification expression.  This could be fixed by
>changing the edit to "A <defined-operator> defined by a specification
>function may be used in a specification expression."

That would be a broken edit, since a <defined-operator> is not EVER defined by a 
specification function.  It is defined by an INTERFACE block or a GENERIC 
statement.

There is a whole pile of extra rules that need to be followed (data type 
considerations, shape conformance, ...).  Being resolved to a specification 
function is merely one of them.

However, the edit should be using "can" (capability) not "may" (permission). 
That avoids giving the impression that the Introduction is providing normative 
requirements (something it is not allowed to do!).

>For F08/0124:
>-------------
>
>While I agree there is a defect that needs attention, the proposed
>"potential subobject component" term is awkward at best,

(a) That is a matter of opinion.  Some might think it the best descriptive term 
available.

(b) This is an interp.  Improving the wordsmithing of a term is not necessary 
and should not be done unless there is an actual better candidate waiting in the 
wings.

(c) It took us a long time indeed to come up with a term even as good as this 
one...

> and has a recursive definition.

I should hope so too!  That is what the question in the interp was about...

That's why we defined it properly as a special term - even though this interp 
only needs to use it in one place.

>  And the resulting constraint would end "has a
>polymorphic allocatable potential subobject component". Not an example
>of clarity.

The constraint is concerned about having (a component that is):
(a) polymorphic
(b) allocatable
(c) a component whose corresponding structure component is potentially a 
subobject (of the base object of the data-ref),
    i.e. a potential subobject component

Seems pretty clear to me.  Verbose, but not unclear.

>  And it appears to say "allocatable nonpointer" which is
>automatically true, since allocatable and pointer are mutually
>exclusive.

The text "allocatable nonpointer" does not and will not appear in the standard.

We could delete the "allocatable" word since a potential subobject component is 
never a pointer component and therefore polymorphic implies it is necessarily 
allocatable, that gives us
   "has a polymorphic potential subobject component"
I don't object strongly to that, but it does require the reader to "prove the 
lemma" that this is necessarily allocatable (otherwise they *might* get confused 
about polymorphic pointer components).

Anyway, deleting "allocatable" (or not) is wordsmithing at a level not strictly 
necessary for an interp.

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