Re: Q: access to subprogram

[bobduff@world.std.com (Robert A Duff)]

In article <4tb4ii$5fc@mulga.cs.mu.OZ.AU>,
Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote:
>You can't represent higher-order types (Mercury's equivalent to
>access-to-subprogram types) using a single code address, you
>need a data address as well -- presuming you don't use trampolines.
>But I thought Ada already imposed that requirement, since you can
>take the address of nested procedures in Ada? (can't you?)

Ada's access-to-subprogram types are rather severely restricted.  Yes,
you can make a pointer-to-nested-proc, but that pointer can't survive
longer than the immediately enclosing procedure.

Define "level of X" to mean "the number of procedures statically
enclosing X", so a procedure in a library package is "level 0", a
procedure in that is "level 1", and so on.  You also need to count block
statements and tasks as levels, but not packages.

Now, an access type at level N can have values pointing at procedures of
levels less than or equal to N, but not greater.

In particular, a level-0 access type can only be used to point to
level-0 procedures.

Various rules ensure the above property.  The special rule for generics
ensures that the above property holds without requiring the compiler to
see the generic body when compiling an instantiation.

For a static-link implementation, a level-0 access-to-proc type can be
implemented as a single address (of the procedure's code).  This is
important, for interfacing to C.  (E.g. passing call-back procedures to
X windows.)  A level-1 access-to-proc can also be implemented as a
single address, since there is only one possibility for the static link,
assuming the run-time model allows level-0 procedures to sometimes get a
static link which they then ignore.  Level-2 and deeper access types
need the pair of pointers you talked about.

A display implementation can always implement access-to-subp as a single
address, at all levels.

Does this help?

>The way the Mercury implementation handles taking the address of a
>generic instance in a shared generic is to package up the generic
>instance data in basically the same way that the stack frame data in an
>enclosing procedure is packed up when you take the address of a nested
>procedure.  So as long as you are already committed to being able to
>take the address of nested procedures, there is no distributed
>overhead -- I think.

Yes, this makes sense, I think, but doesn't it imply that level-0
access-to-proc types have a static link attached?  That would constitute
a distributed overhead, would it not, given the stuff I said above?  And
make the interface to C more painful?

- Bob