Thorsten Ohl writes:
 >     Constraint: A procedure-name actual-arg shall not be the name of an
 >     internal procedure or of statement function and shall not be the
 >     generic name of a procedure unless it is also a specific name
 >     (12.3.2.1, 13.1).
 > 
 > Why?  If there is an INTERFACE for the actual-arg, the compiler should
 > have enough information to resolve the generic name.
 > 
 > Is this going to change?

I must repeat the usual caveat in answering any question that begins
with "why".  The only actually corrrect answer to a "why" question
about the standard is "because that's what was voted in."  Any other
answer is nothing but speculation about the state of mind of the
people voting.  There are *SLIGHTLY* better grounds for such
speculation in this case than in the political arena - but not as
much as you might think - or you wouldn't phrase the questions with
"why".  I sometimes can't recall my own reasons for voting for
something, much less other people's reasons.  People are not obligated
to state the reasons for their votes (though they often do), and
if they do state reasons, there is no guarantee that the stated
reasons are the "real" ones.  That being said..

Let me first answer the part that you didn't specifically mention in
your query.  Calling an internal procedure or statement function has
complications with recursive procedures.  It would likely be necessary
to pass not only the address of the procedure, but also the address
of an "activation record" (or I'm told that's what compiler-types
call it) of the particular instantiation of the host so that the
internal procedure gets the right copies of host-associated things.
This is alleged to be possible, but it would have been an extra
complication in a language already criticised as being too complicated
(this stuff was added in f90).  The demand was judged not worth the
extra complication..at least by a majority (I wasn't there and its
not clear whether or not this judgement was universal).  I was there
when it was proposed to relax this part of the restriction in f95.
It was proposed - didn't get enough votes.  One might suspect that
a majority felt the benefits not worth the cost.  This is, however,
purely speculation about motives.  Anyone who claims to know more
definitively is misleading you.

On generics, your statement presumes an explicit interface for the
called procedure, and that that explicit interface includes an
explicit interface for the dummy (not for the actual as you
incorrectly state - there is no syntax to directly specify an explicit
interface for actual arguments; you can specify the interface for a
dummy, which places compatability requirements of the actual).

Thus, at a minimum, there would have to be a set of conditions to be
met in order to allow this.  Getting those conditions right would be a
bit of a complication, with questionable payback for the complication.

And now what happens when the procedure you are calling is generic?
You are relying on knowledge of the procedure interface to determine
the type of the actual argument.  And then you are relying on the
type of the actual argument to determine which procedure to call.
This circular dependence might not have a unique resolution.  I'd
call this just another case of the general rule that types of things
are not determined by context.  Generic resolution is controlled
by the types of the arguments to the generic - not by the context
in which the generic is used.  In this case, you aren't actually
giving arguments for the generic.

This all may be resolvable, but it is not at all trivial.  Indeed,
I'd see it as pretty complex - including consideration of possible
cases where you might want to actually pass a generic as a generic
instead of seleting a specific to pass...and that would certainly
be a substantial language addition.

One final thing to keep in mind for questions of this general nature:
There really doesn't have to be concrete reason for a proposed feature
to be rejected.  Every feature added means work for the committee and
for implementors.  There have been more worthwhile features proposed
than there is any hope of getting done.  Any work put into one feature
is work that won't be put into some other feature.  So the real
question is seldom "is this feature a good idea?"  Its much more often
"is this feature more important than the others that won't get done
if this one is done?"  There are features that get rejected because
a majority thinks them just plain a bad idea, but far more things
get rejected on the basis of not being important enough to get the
needed share of the finite resources available.

How does one "explain" rejection of an idea that a clear majority of
the committee thinks is a good idea...but just not important enough?
You can't point out specific things wrong with it - there may be none.
One ends up falling back to the "it just didn't get enough votes",
which is, in the end, the real reason.

-- 
Richard Maine
[log in to unmask]



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%