I wrote:
> > Agreement of type name is not important - only agreement of the
> > characteristics represented by the name.
> >
> > This makes the name unsuitable for disambiguation
Peter Shenkin writes:
> Here I disagree, especially with the last sentence. For one thing,
> it's not in the spirit of the way disambiguation is done for
> derived types in F90....
>
> Yet type1 and type2 can be used for disambiguation in generic
> functions. For derived types it has never been the underlying
> characteristics (the content of the data structure) but purely
> the type name that is the basis of disambiguation, as I understand
> it -- please correct me if I'm wrong. This is, IMHO, the right
> way to go.
>
> For procedures, we need do nothing more, and should do nothing
> less.
First, pardon my sloppy wording, by the way. Its not really a "type
name"; I shouldn't have used that term; its an abstract interface
name. But to continue.
There are already substantial differences in the issues of procedure
interface compatability and type compatability. I'm not sure how
to integrate these existing differences with a strict typing concept
where the name was important. For example:
We have no way to establish a name for the interface of the procedure
itself. It just has whatever characteristics it has. If we have
"strict typing" of interfaces, then I'm not sure how we can allow
a procedure pointer, typically declared using an abstract interface
name, to point to the actual procedure, which is not going to have
the same abstract interface name; all it will have is characteristics
that match.
And then there is the issue that a procedure is allowed to be
described by different interface bodies in different scopes.
The interface bodies don't even have to be the same in all
regards. The standard specifies the ways in which they must
be the same. But they can, for example, have different dummy
argument names. I'm not sure how to reconcile this situation
with a requirement that you must have name matching of abstract
interfaces.
Perhaps part of the problem here is that we already in f90 (and 95)
have interface bodies that don't have anything like a "type name".
It seems to me to be difficult to both be compatable with this
precedent of not having names for interfaces at all, while at
the same time requiring the names to be significant. Note that
f90 doesn't have unnamed structures. The only way to have a
structure is to have a named derived type.
I'm not sure I necessarily like the conclusions this leads to.
But at least as currently proposed, named procedure interfaces
are more a syntactic convenience than a major new semantic
feature. Note in particular that you won't find them on the
list of new features adopted for f2k. They are just a part
of the procedure pointer proposal. Some such syntax was
needed or declaring procedure pointers would have been pretty
bad. (You'd have had to write a separate interface body
for every procedure pointer, which would have been unacceptably
awkward in my opinion - and evidently enough others agreed
that the notion was accepted).
--
Richard Maine
[log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|