(j3.2006) (SC22WG5.4806) [ukfortran] WG5 letter ballot 4 on Fortran 2008 interpretations
Malcolm Cohen
malcolm
Fri Sep 28 04:35:36 EDT 2012
<<<
-------------------------
F08/0048 C
While I see no problem with implementing the feature as described in
the proposed interpretation, I would agree to defer approval of the
interpretation until after further consideration of Malcolm's
objections.
>>>
That's just bizarre. I raised no new technical issue, having voted the same way
at every previous vote (this interp originally went the other way - at that time
I voted Yes, various people objected and now the interp goes the other way - so
I have voted No twice already).
It's not "further consideration" that is needed, it is a policy decision as to
which way to go (the standard as written, or as Bill and John intended it to be
written). I have had my say.
>-------------------------
>F08/0054 N
>
>I think that the proposed interpretation is a misinterpretation of
>what was intended by paper 02-144.
Paper 02-144
***DID NOT INTEND TO MAKE A TECHNICAL CHANGE***
Not even a small one.
(Either that or the authors secretly wanted a technical change and got it past
the committee by subterfuge. I do not believe that is the case.)
...
>The reason I am voting "no" on this interpretation is that the
>proposed edits are incorrect. The text of the relevant portion of
>the standard is also erroneous.
>
>I assume that the term "procedure identifier" is meant to include
>operators and the names of procedures and procedure pointers. The
>problem is that a generic identifier appears to fall under this
>definition. A generic identifier does not have either implicit or
>explicit interface.
Huh? The edit says
"Within the scope of a procedure identifier, THE PROCEDURE shall have an
explicit interface"
Nothing about generic identifiers having an explicit interface.
> I do not see how the proposed edits apply in
>the case of a generic identifier.
Seems clear enough to me.
>As I thought about the issue, I convinced myself that the property
>of having implicit or explicit interface should apply only to the
>names of procedures and procedure pointers, and not to procedures
>themselves. Because of renaming, a single procedure can have more
>than one name in a given scoping unit. The properties of each name
>might be different. For example, a function F might be identified
>by the names G and H in a scoping unit. The names of the dummy
>arguments of G and H might be different.
They would still both have explicit interfaces though...
I am reluctant to completely rewrite the way the standard describes interfaces
to procedures along the lines suggested, in an interp. I agree that the
language could be better, but apart from not being entirely convinced that the
suggested approach would actually be an improvement, I think that the right time
for rewriting the whole method of description must be in a revision, not an
interp.
>-------------------------
>F08/0063 N
>
>This interpretation upends the meaning of item (5) in Clause 10.7.2.1.
No it does not.
>A similar argument could be made against any application of item (5).
That is completely untrue.
F6.1 makes sense and according to item (5) will produce asterisks for large
values e.g. 1e8.
E10.2E2 makes sense and according to item (5) will produce asterisks for large
enough values e.g. 1d200.
>I am surprised anyone thinks that editing under an F4.5 edit
>descriptor should be permitted to produce anything other than four
>asterisks.
F4.5 does not make sense. The standard does not make sense of F4.5, so it does
not say *anything*.
> Under the proposed interpretation, I have no idea what
>should be expected as a result of editing under an F4.4 edit
>descriptor.
The same as any non-conforming program. Anything.
It would be a good idea to require F4.5 to produce 4 asterisks in the next
revision, sure looks like a wart to me.
>-------------------------
>F08/0067 C
>
>I agree that the program should not be standard conforming, and I agree
>that the edit provided ensures that it is not. I do not agree with the
>rationale given for the answer. Whether the invocation of SUB2 in SUB1
>does or does not require the shape of A depends on the argument passing
>conventions used by the processor. While all or almost all existing
>Fortran processors use copy-in/copy-out to pass the array argument to
>SUB2, the Fortran standard does not require a conforming processor to
>use copy-in/copy-out. Other argument passing conventions exist that do
>not require making a copy in this case. Those conventions do not
>require the shape or size of A to be known.
Yes, but no-one uses such a convention. (Non-polymorphic assumed-size arrays
get passed with "stride" information, are you serious?)
I mean really, one could argue that assumed-size arrays can be used everywhere
because you never need to know the shape, you only need to know the stride and
the location of the last element.
Cheers,
--
................................Malcolm Cohen, Nihon NAG, Tokyo.
More information about the J3
mailing list