Calling functions whose signature/arguments are only known at runtime

[Andrew Whitworth]

On Wed, Mar 17, 2010 at 9:49 AM, Peter Lobsinger <plobsing at gmail.com> wrote:
> Are you saying that this is both a supported and recommended way of
> calling into Parrot? For a subsystem that seems to get refactored
> frequently, I *really* don't want to break encapsulation.
>
> The lack of docs makes me wary. For example, looking at the output of
> "perldoc callcontext.pmc" is not very helpful, you have to RTFS to
> figure out that you can use push_{string,integer,float,pmc} to build
> up a CallContext PMC. Also, I'd like this technique to show up in some
> tests, examples, and/or extending/embedding doc. (Yes, I know I've
> just volunteered, it's been added to the queue)
>
> If this method covers everything, why do we expose functions to do the
> same thing? Is this just vestigial code? I especially dislike the
> functions with misleading names like "sig_object" when we really have
> a CallContext.

I'm not sure what the recommendation is. I can tell you that it is
supported. Parrot_pcc_invoke_from_sig_object is the core calling
routine in the PCC system, and I can't imagine it's going away or
going to be changed any time soon. It's taken us quite a long time to
get it working the way we want it now.

That said, while I say it's possible, it might not be the
recommendation. Instead, it may be recommended to call Parrot_ext_call
with a signature of "Pc->Pc" (where "c" is a
planned-but-not-yet-implemented signature modifier to specify that
this is the CallSignature object) and a CallContext PMC as an
argument. This technique is definitely being wanted in PIR code, and
having it available from C maintains nice symmetry.

Which of these two methods is the recommendation is a matter probably
left to Allison, though I don't see a problem with using either. Of
course, we may want to keep our embedding interface short and simple,
and avoid exposing internal-only functions there.

As to the lack of docs, that problem is hardly specific to PCC and
CallContext. As a bit of an excuse I will note that, as you've pointed
out, this system has seen a lot of refactoring recently. I think we're
getting to a good stable point where big things won't be changing as
much and we can start focusing effort on improving the documentation
and known best practices. The docs should improve, and I'll see if I
can work on that too.

Parrot_ext_call and Parrot_pcc_invoke_from_sig_object don't exactly do
the same things. Parrot_ext_call is specifically designed to work from
C and take arguments as C datatypes. Plus, it gives us a convenient
place to add context entry and exit code, thread synchronization code,
or GC management code (turn off GC, such as a concurrent GC, when we
exit managed code), etc. I don't think we do any of these things yet,
but I can imagine many reasons why we will want to.

--Andrew Whitworth




>