At 10:23 PM 1/18/00 +0100, Phillip Helbig wrote:
>My response would be, allow it for non-recursive hosts. I guess the
>motivation for disallowing (obsolete) statement functions is similar;
>why are generic names not allowed? Does this restriction also apply to
>intrinsic generics?
The motivation for statement functions was different -- statement functions
are typically implemented by in-line expansion, so there is manifestation
with standard calling sequence to associate with the dummy procedure.
Generics are a collection of specific procedures with rules to decide which
specific procedure should be called for particular arguments. The
committee felt it would be awkward, at best, to support generic dummy
procedures that would associate with the totality of that information.
There is one case where a generic name can be used as an actual argument
associated with a (specific) dummy procedure - if the name is both generic
and specific (e.g., "sin" is both the name of the generic sine function and
the name of the specific function that calculates the sine function for
default real arguments), it can be used as an actual argument denoting the
specific procedure.
These rules and restrictions apply to intrinsic generics in the same way as
user-written generics. (Note, however, that some intrinsic procedures are
restricted from being used as actual arguments even if the specific name is
available.)
If the procedure being called and the dummy procedure are both explicit,
one could argue that one should be able to pass a generic and have the
"right" part of the generic be associated with the dummy procedure, but
this gets complicated in the general case. (For example, the dummy
procedure might accept a single argument while the "corresponding" specific
in the generic might have two dummy arguments with the second one
optional.) Rather than make the compiler deal with all the strange cases,
the committee chose to require the programmer to explicitly create a
specific procedure that invokes the generic procedure. This decision could
be revisited, but there hasn't been much (any?) demand for this so far.
>
...
>> There was, however, a remark inserted in Annex C that if a processor
>> implements the ability to pass internal procedures as actual arguments,
>> then deep binding should be used to determine the correct instance of
>> the host environment.
>
>OK, but this would be non-portable and non-standard.
1. This was the f90 committee's way of telling future committees that if
they remove the restriction in a future revision, the resulting behavior
should be consistent with deep binding.
2. This was the f90 committee's way of telling implementors that if the
restriction is removed in the future, it will require deep binding, so any
extensions implemented in this area now should also use deep binding to
avoid being incompatible with future standards.
You're quite right that this does not give you anything portable to use now.
--
Kurt W. Hirchert [log in to unmask]
Center for Computational Sciences +606-257-8748
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|