William F Mitchell writes:
> Consider a generic interface for subroutines that take a dummy procedure as
> one of the arguments. If an interface block is given for the dummy
> procedure, should differences in the interface block be sufficient for the
> dummy procedures to be "different types" in the context of resolving the
> generic interface?
No. See section 14.1.2.3, which is too long to quote in detail. But
you've actually cited the most critical words above when you said
"different types". The standard, however, does not use the quote
marks. More completely, it talks about differences in "type, kind
type parameter, or rank". A difference in the interface block of
a procedure is not, in general, a type, type parameter, or rank of
the procedure. It is a difference in the charactersitics of the
procedure, but section 14.1.2.3 doesn't say that characteristics
of a dummy procedure argument may be used in resolution - just
type, type parameter, or rank.
Indeed, notice, that "procedureness" can't even be used for generic
resolution. You can't have two specifics, one of which takes a real
data value, and the other of which takes a real function. You may,
however have two specifics, one of which takes a real function, and
the other of which takes an integer function. This is because
a real function and an integer function differ in type.
> On the other hand, if the actual argument is a procedure whose
> interface does not match the dummy procedure interface, about half the compilers
> generate a type mismatch (which is what I would expect).
That's a different matter. The rules for what can be used to
disambiguate generic overloads (section 14.1.2.3) are different from
the rules for how actual and dummy arguments must match (12.4.1, and
for dummy procedures, see specifically 12.4.1.2).
In general, I might sloppily say that a difference must be "stronger"
to be usable as a disambiguator. Just because a set of arguments
would be illegal for one specific doesn't mean that the particular
illegality is sufficient to form a basis for generic resolution.
(I've worded this really sloppily and not at all like the words of the
standard).
> option left is to use EXTERNAL for the dummy procedure instead of an interface
> block, but then the subset languages won't work.
I thought the subset languages were intentionally picky about
argument disagreements. Its not shocking that you have difficulty in
fooling them into accepting such. In any case, I'm not qualified to
answer interpretation requests about the subset languages.
> Has this one ever come up for interpretation?
I recall quite a bit of discussion of such issues in interps.
Details not handy at the moment without spending more time than
I have to spare (there are about 200 interps, with no particular
organization).
--
Richard Maine
[log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|