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.
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.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|