At 10:46 AM 1/19/00 -0800, Van Snyder wrote:
>
>I wrote:
>
>>Unfortunately, the former one (the one usually considered to be more
>>useful) requires passing extra junk in the calling sequence -- that is,
>>a pointer to the correct instance of the host environment, as well as
>>the procedure entry point....
>
>and Kurt Hirchert wrote:
>
>! There are alternatives to "passing extra junk" in implementing deep
>! binding. For example, it would be possible in recursive hosts to create
>! shadow procedures on the stack that "hard code" the up-link for the current
>! instance of the host and then transfer to the normal implementation of the
>! internal procedure.
>
>This is equivalent to creating a structure with a pointer to the host
>environment and a pointer to the entry point, and then putting this or
>its address in the calling sequence. There is the same distinction
>concerning passing type parameters (today, only character length).
>I see it as a distinction without a difference.
Since the primary objection was not to the "extra junk" itself, but to the
idea that passing "extra junk" would break object compatibility with code
produced by f77 compilers, the approach of encapsulating that "extra junk"
in information that _can_ be passed through the f77 interface seems a
significant difference to me.
>
>I wrote:
>
>>The up-link is entirely unnecessary in the non-recursive case, and, in
>>fact is unnecessary in the case the the host procedure has no dummy
>>procedure arguments, or even if it has dummy procedure arguments with
>>explicit interfaces that are incompatible with the internal procedure.
>
>and Kurt Hirchert wrote:
>
>! The first line is true, but the rest is not. The up-link is required if
>! _anything_ instance-specific is used from the host environment, not just
>! the host dummy procedure, so the absence of host dummy arguments doesn't
>! guarantee that the up-link is unneeded.
>
>If another instance of the host of an internal procedure can't come into
>existence between the time an internal procedure is bound as an actual
>argument, and the time it's used by way of a dummy argument, then shallow
>binding and deep binding refer to the same instance. The latter two cases
>above rule out the possibility of the internal procedure passing through
>a recursive invocation of its host after being bound as an actual argument.
>
>In the case of shallow binding, a procedure can keep a stack of pointers
>to its instances, and an internal procedure can look at the top of the
>stack to find its host environment. It isn't necessary to pass the pointer
>to the host environment in the calling sequence.
OK. I'll make that "half true". In pure f90, it is true (for the reasons
you cite), but in f90 processors with extensions such as the procedure
pointers being introduced in f2k, it is not (because the chain of argument
association is no longer the only way to have access to a dummy procedure).
It might be appropriate to optimize based on these conditions (if you know
your processor doesn't implement procedure pointers), but I wouldn't want
to use these conditions as the basis for loosening the restrictions in the
standard (because as standards writers we don't know what extensions the
processor may have implemented).
--
Kurt W. Hirchert [log in to unmask]
Center for Computational Sciences +606-257-8748
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|