(j3.2006) request for interpretation
Kurt W Hirchert
hirchert
Fri Apr 4 16:41:31 EDT 2008
The text in subclause 12.4.4 was originally written after a thorough
consideration of the specific issue being now being addressed -- how
generics should interact with host association. Indeed, the parts of
12.4.4 not about that issue were written primarily to provide a
framework in which to address this specific issue. In constrast, I am
not aware of any consideration being given to this issue during the
writing of what is now 16.2.3, nor am I aware of any consideration being
given to this issue during the original writing of what is now 16.4.1.3,
although some limited consideration was given during one of the
revisions of this material. For that reason, I believe that 12.4.4 is
significantly more likely to represent both the technical intent of the
committee and the way these features _should_ interact than an
interpretation based on reading 16.2.3 and 16.4.1.3, despite the fact
that one must do some "reading between the lines" to get some of the
answers from 12.4.4.
It has been suggested that the proposed interpretation based on 16.2.3
and 16.4.1.3 does not conflict with 12.4.4. I find this suggestion a
bit disingenuous. There may be no "letter of the law" conflict, but
there is a clear conflict in spirit, for there would have been no reason
to write 12.4.4.1 the way it is written if the proposed interpretation
is what was intended.. Thus, I am inclined to distrust that proposed
interpretation until someone provides an adequate associated explanation
for the mismatch.
Accordingly I took another look at 16.2.3 and 16.4.1.3 to see if the
proposed interpretation might be missing something. I found two things
worthy of at least some consideration:
In 16.2.3, the issue is not whether the two procedures conflict by the
rules of 16.2.3, but whether those rules should be applied to that pair
of procedures. What 16.2.3 has to say on the subject is in its very
first sentence: "This subclause contains the rules that shall be
satisfied by every pair of specific procedures that have the same
generic identifier within a scoping unit." If we interpret the phrase
"with a scoping unit" in a physical sense, then I submit to you that a
procedure in the host of a scoping unit is not physically "within" the
contained scoping unit. If you accept that, then this first sentence is
a somewhat subtle expression of the expectation in 12.4.4.1 that the
rules of 16.2.3 are to be applied to explicitly declared procedures and
to procedures made accessible through use association, but not to those
accessible through host association.
Although I believe the above is a plausible reconciliation between
12.4.4.1 and interpretation based on 16.2.3, I fully expect that some
will assert that the phrase "within a scoping unit" was not meant
physically and that host association logically places the host's
procedures "within" the contained scoping unit, so let us also consider
16.4.1.3. After carefully looking at the second paragraph of 16.4.1.3
(the one contained the long numbered list), I conclude that it is just
plain "broken" in what it has to say (or more precisely, in what it
doesn't have to say) about generic names. I can construct many
different kinds of examples of this brokenness, but let's start with an
easy one. Consider the following program fragment:
MODULE M
INTERFACE F
FUNCTION FR(X)
REAL X
END FUNCTION
FUNCTION FI(I)
INTEGER I
END FUNCTION
END INTERFACE
CONTAINS
SUBROUTINE SUB
INTEGER F(100)
...
X1 = F(1.0) !legal?
X2 = F(1) !legal? if so, does it reference function or
array?
...
END SUBROUTINE
END MODULE
As I see it, the relevant sentence from the second paragraph is "A name
that appears in the scoping unit as <long list of usages including
entity declaration> is a local identifier in the scoping unit and any
entity of the host that has this as its nongeneric name is inaccessible
by that name by host association." Thus the declaration of F in SUB
would block access to F in M if F were nongeneric, but since it is
generic, both Fs should be accessible in SUB. [I am applying
essentially the same logic that was being used to assert that both
versions of SUBR should be accessible in S of Robert Corbett's
example.] In theory, one could write a compiler that handled the
assignment to X1 (although I doubt any existing compiler does so), but
for the assignment to X2 we have neither an analog of 12.4.4.1 to tell
us how to interpret the reference to F nor an analog of 16.2.3 to say it
is not allowed.
This example exploits the problem with the word "nongeneric" in the
third sentence of the paragraph, but one can construct similar examples
to exploit the word "nongeneric" in the first, second, and fourth
sentences, as well. If these sentences are broken for these examples,
we can not trust them in Robert Corbett's example either. In fixing
these sentences, we may eliminate the conflict between 12.4.4.1 and
interpretation based on 16.2.3 and 16.4.1.3.
How did these sentences become "broken"? I will offer some speculation
based on hazy memories, but unlike the case with 12.4.4, I was not
involved in writing these words, so my memories are only of brief
discussions in full committee, and it is quite possible that they are
wrong. It appears that the events I "remember" date back to a time
before X3J3's records were electronically archived, so I couldn't find
confirmation there. I would encourage anyone on this list that was also
on the committee during the development of Fortran 90 to contribute
whatever they can remember on the subject.
If my memory is correct, the original version of this paragraph did not
contain the word "nongeneric". Thus, any local declaration of a name
blocked access to the host's meaning for that name, whether or not the
names were generic. At some point, it was observed that this appeared
to be in conflict with the text now in 12.4.4.1, where in limited cases
declaration of a local generic might not fully block access to a
compatible host generic with the same name. This apparently was at a
point when we were attempting to minimize the editorial size of changes
made to the document, so rather than restructuring this text so only the
one very specific case was allowed, the word "name" was qualified with
the word "nongeneric" in several places. I think it was assumed that
text elsewhere would take care of the fact that this change was overly
broad, but since we were dealing with lots of editorial changes and
"integration", it appears no one actually checked.
How should we fix this paragraph? If our intent is to correctly what
was originally done wrong, we would need significantly restructure the
paragraph, separating the identification of all the things that
constitute a local declaration of a name from its effect on host
association. We could then say in one place that local declaration
prevents host access except in the one special case. In one sense, this
might be the "right" solution, but I suspect that it would be painful,
both editorially and in the determination of language to describe the
one special case.
As a possibly simpler alternative, I suggest striking all occurrences of
the word "nongeneric" in this paragraph and adding a note to the effect
that although a local generic blocks access by host association to a
generic with the same name in the host, the rules in 12.4.4.1 will,
under some circumstances, cause a reference to the local generic to
resolve to being a reference to a specific from the generic in the
host. In effect, we get out of our editorial bind by calling our
special case something other than host association. (We could go
further and give a name to this something else, say "host generic
association", and add another short subclause to 16.4.1, describing it,
but since the point of this suggest was to reduce the editorial load, I
am not proposing that myself.)
Summary recommendations:
The second paragraph of 16.4.1.3 needs to be fixed no matter what answer
is given to Robert Corbett. If I am right that the original change in
this paragraph was done solely to reconcile it with what is now
12.4.4.1, then I can see no justification for not fixing it to be
consistent with that subclause. In the interests of minimizing the work
involved, I recommend my "simpler alternative" above for the fix.
My own inclination would be to also clarify the first sentence of 16.2.3
to apply only to what 12.4.4.1 implies, but it if 16.4.1.3 is fixed as I
suggest, this is not absolutely necessary.
Of course, all of this leads to my original interpretation, that Robert
Corbett's example is standard conforming.
-Kurt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3-fortran.org/pipermail/j3/attachments/20080404/bbd15d9c/attachment-0001.html
More information about the J3
mailing list