Re: Q: access to subprogram

[davidk@OS2.ifs (David Kristola)]

In article cbo@mulga.cs.mu.OZ.AU, fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>rogoff@sccm.Stanford.EDU (Brian Rogoff) writes:

[snip] (I apologize if i am attributing these words to the wrong person, i was
not able to locate the original post).

>>If 'Access is allowed in generic bodies, generic code sharing requires
>>distributed overhead.  (Or compilers have to do body analysis of generics
>>in order to prevent sharing on them).

Maybe i am misunderstanding the meaning of "distributed overhead", but don't
all shared generics have some?  But anyway...

[snip]

>>To explain this in detail, I'd have to give a crash course on the construction
>>of shared generics.  However, here is a simplified version of the problem:
>>A shared generic passes in some way a pointer to a data area identifying the
>>generic, and containing its local objects.  [Note that this exists in any but
>>the most simplified versions of sharing - any sharing algorithm which allows
>>data in the generic specification or body would have the problem].
>>However, an access-to-subprogram does not know that the routine comes from
>>a generic, or even which generic.  The solution to this problem in the
>>specification is to construct a 'wrapper' routine at instantiation time,
>>which knows about the appropriate generic instantiation.
>
>I think I follow you so far...

This is how i understand generics with shared code to work.

>>However, a wrapper cannot be built for 'Accesses in the generic body
>>inside the generic body. 
>
>Can you explain in a bit more detail when this would be necessary,
>and why it is not possible?

Maybe a code example here would help (let me know if i have missed the mark):

generic
   ...
package Pkg is
   procedure P;
end Pkg;

with ...
package body Pkg is
   function F(...) return ... is
      ...
   begin
      ...
   end F;

   procedure P is
      ...
   begin
      ...
      Call_Something(F'Access);
      ...
   end P;
end Pkg;

Since F might depend on the generic parameters to Pkg, F'Access would need to
point to a wrapper for F, which is not known inside Pkg at compile time (there
may be no instantiations, and therefore no wrappers created).  I do not know if
F would have it's own wrapper anyway, because it is not visible in the spec of
Pkg, and therefore not externally callable.

BUT, why not have a wrapper for F, and, include in the instantiation data, the
addresses of the wrapper routines (F in this case), so that P could reference the
instantiated data passed to it to get the address to resolve F'Access?  There is
a bit of indirection here, but then that is an everyday part of shared generics.

I hope my mostly Ada 83 view of the world has not blinded me to something in Ada
that makes this approach fail (or some general blindness to a common feature
that i have overlooked).  And before i start a flame war, this is just a comment
on how such a thing could be done, please do not point out the RM sections that
forbid it (that is not the point).

>--
>Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
>WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
>PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

david kristola
"maybe i would not see the solution so clearly if i could see all of the problem"
Work: davidk@os1.ese.lmsc.lockheed.com
Play: DJKristola@aol.com

My suggestion for Lockheed Martin's next slogan:
"Lockheed Martin, we make things that go BOOM!"