(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, 
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, 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 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 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 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 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 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  After carefully looking at the second paragraph of 
(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
          FUNCTION FR(X)
            REAL X
          END FUNCTION
          FUNCTION FI(I)
            INTEGER I
          END FUNCTION
          INTEGER F(100)
          X1 = F(1.0)     !legal?
          X2 = F(1)       !legal? if so, does it reference function or 
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 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 and 
interpretation based on 16.2.3 and

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, 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 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 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, 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 implies, but it if 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.

-------------- 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