From: Van Snyder <[log in to unmask]> wrote:
> Phillip Helbig asked:
>
> > Can someone (re)state the rationale behind this?
>
> > I am finding this increasingly annoying.
>
> > I have a subroutine which has several dummy arguments, including a
> > procedure name. Fine. I have a function which I want to pass as an
> > actual argument to another subroutine. Fine. This function uses some
> > of the arguments of the initial subroutine. It would seem natural to
> > make this function internal to the first subroutine, so that it can
> > access the needed arguments through host association. However, if I do
> > this, I cannot pass it as an actual argument to the second subroutine....
>
> The problem is that if a procedure that is internal to a recursive host
> is passed as an actual argument, which instance of its host is used for
> host associated entities when the procedure is invoked by way of the
> dummy argument?
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?
> There was a proposal at the February 1997 J3/WG5 meeting, the last meeting
> at which proposals for functionality were accepted, to allow internal
> procedures of nonrecursive hosts to be passed as actual arguments, but
> it didn't make the priority cutoff.
So no fundamental reason; maybe there's a chance in the future.
> 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.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|