(j3.2006) J3 Fortran interp letter ballot #15 - due 10-Feb-2008

[Malcolm Cohen]

I don't have a formal vote at this stage but I do have views...

> Subj:   J3 Fortran interp letter ballot #15 - due 10-Feb-2008
>
> Yes   No    Number     Title
>
>
> -C-   ---   F03/0003   Referencing deferred bindings
>
> -C-   ---   F03/0004   Type-bound procedures and undefined association
>                         status
>
> -C-   ---   F03/0079   Value of decimal exponent for a real zero value
>
> -Y-   ---   F03/0080   Formatted output of a negative real zero value
>
> ---   -N-   F03/0099   Clause 16 does not account for volatile variable
>
> ---   -N-   F03/0100   Error in field width for special cases of signed
>                         INFINITY output
>
> ---   -N-   F03/0102   Evaluation of bound-expr in data pointer
>                         assignment
>
> ---   -N-   F03/0103   Restrictions on dummy arguments not present for
>                         polymorphic type or parameterized derived type
>
> -C-   ---   F03/0104   Deallocation and finalization of bounds-remapped
>                         pointers
>
> ---   -N-   F03/0105   SIZE= specifier and UDDTIO
>
> -C-   ---   F03/0106   Inquire by unit inconsistencies
>
> ---   -N-   F03/0107   Are the IEEE_* elemental routines required
>
> -Y-   ---   F03/0108   Is IEEE_SUPPORT_NAN consistent with the other
>                         IEEE_SUPPORT functions
>
> ---   -N-   F03/0109   Referencing deferred binding via absent dummy
>                         argument

Comments and No "votes".

F03/0003 Comment

I agree with Jim Xia's suggested change to the example.

F03/0004 Comment

The DISCUSSION section is ok as is.
It would not hurt to singularise it, but that is unnecessary.

Bill Long's suggestion is ungrammatical (mixes singular and plural).

The point of "... always require there to be an object" is that we
are talking about pointers here, and that we're that there be an
object in question.  We're not requiring the object, just that there
be one.  (With disassociated/undefined, there is no object.)

F03/0079 Comment

The discussion seems subtly wrong-headed - not wrong enough for me to
vote No, but enough to raise questions.

The discussion focusses on what the effect of a scale factor is, but
the EN and ES edit descriptors explicitly say that the scale factor
has no effect; any implementation that formats EN/ES differently
IN ANY WAY due to scale factor is not conforming already.

But anyway, shouldn't we just say that the "exponent value" of a real
zero is zero?

F03/0099 No

In the first edit, everything past the first sentence is redundant,
unnecessary, and unwanted; it is covered by 16.4.2.0.  Indeed, if it
were not covered by that, we would need to produce these extra words
in many other places.

I disagree with the second and third edits not being list items - we
might as well do away with the whole list in that case!  Perhaps
someone was worried about the "might" in the list - well, we are
already in the "sometimes" situation for INQUIRE, I don't see what
is so different here.

F03/0100 No

Firstly, the "then" should be a comma - see nearby sentences in the
standard for examples (this is English not Fortran).

Secondly, the last sentence omits the case of w==0, which is now
unspecified.

F03/0102 No

The example is already not conforming - see [128:6-7].

Just because the standard has another redundant sentence is not
sufficient reason for adding more.

According to 16.5.5, changing the pointer association can cause
definition, so that bit is definitely unnecessary.  I don't
immediately see the corresponding version for 16.5.6 - that would
appear to be an omission in its own right (unrelated to the example
given or any legal mutation thereof).  If that omission is fixed
(or if it is there and I just didn't spot it) this interp (after
fixing the example) probably needs no edit at all.

F03/0103 No

The DISCUSSION is completely irrelevant unless we are talking about
POINTER/ALLOCATABLE, which we are not.

I probably disagree with the assertion that these two
situations "is" or were intended to be allowed.

The question needs some example code we can say is right or wrong.
(With some example code maybe I could say whether or not I actually
agree or disagree with the bold assertion in the ANSWER!)

The edit makes the following code fragment legal:

   Subroutine one(x)
     Double Precision,Optional :: x
     Call two(x)
   End
   Subroutine two(y)
     Real,Optional :: y
     ...

I can categorically state that we definitely did NOT intend this
to be legal!

F03/0104 Comment

I agree with Bill Long that "are" should be inserted before "processed"
in the first sentence.

Furthermore, the first sentence should begin "The standard" at a minimum.

F03/0105 No

I don't quite follow the reasoning behind this one; it appears to me that
the characters are being transferred by the DT edit descriptor
(proxied via the child i/o procedure).

It is also a horrible restriction that cannot be detected statically.

F03/0106 Comment

I disagree with Bill Long's suggested changes for POS= and NEXTREC=.
The existing wording is entirely talking about "the file"; well, if
the unit is connected *there is no file*.  So either it is unspecified
for an unconnected UNIT=, or the standard seg faults on the nonexistent
file.

F03/0107 No

As a matter of principle an interp should be seeking to make the
smallest possible change.  Insertion of a large note is out of order.
Those who are interested in the answer will be reading the discussion
in the interp request.

F03/0109 No

This edit is being done to the wrong text.
Restrictions on the use of nonpresent dummy arguments are meant to be
in the subclause "Restrictions on dummy arguments not present".

Furthermore, I see no corresponding restrictions for object-bound
procedures.  These are invoked via <proc-component-ref> which is
<variable>%<procedure-component-name>.  This is not a <designator>
so is not covered by item (5) in 12.4.1.6.  (This will affect lots
of usages, not just invocation.)  Yes, I appreciate that that wasn't
quite the question asked by the interp but since these two things
are so similar we should consider them both.

Cheers,
-- 
................Malcolm Cohen (malcolm at nag-j.co.jp)