PCC and playing with arguments from C

[Allison Randal]

Florian Hatat wrote:
> It looks like some bits of my previous message got lost (probably
> between my chair and the keyboard), so I'm resending it.
> 
> I'm trying to write a PMC which handles curried subs (i.e., subs which
> only run when provided with enough arguments, when there are too few of
> them, it just stores the given arguments, then returns a new sub which
> only expects the remaining arguments).
> 
> Writing it in PIR is (for the moment) excluded because of ticket #103.
> (I have no way to retrieve previous arguments without "self" in "invoke").
> 
> So I'm trying to write the PMC in C. Unfortunately, I have no idea of
> how to play with arguments from C, and Parrot's documentation so far has
> not be very helpful.
> 
> Has someone got a few examples of, say:
> * retrieving the number of arguments passed to the sub (the idea would
> be to do that quickly without moving arguments: when there are enough
> arguments, I just want to run the actual code),
> * moving them around (to store them in a ResizablePMCArray, for example)?
> 
> I looked at PDD03, but this mainly talks about PIR, and tried to
> understand what functions in src/call/pcc.c do (I have the feeling that
> my answer is in there, because of the code generated for METHODs in
> PMCs, yet running perldoc pcc.c was not very useful to me).

This would be difficult at the moment, because the arguments are passed 
around the system in C varargs or in direct pointers to a chunk of 
memory that stores register numbers/constant indexes (depending on where 
and how the sub was called). And yes, the current C-level docs for the 
calling conventions aren't very helpful.

That is all changing as we speak. My current work is to clean up the 
internals so the various different ways of invoking subroutines all put 
their arguments into a call signature object, which can be easily 
manipulated. (I'm through the PIR-calls, C calls are next.)


That said, does currying necessarily need to use the 'invoke' vtable 
function? I understand that at the language level it should look like 
invoking the sub with too few arguments returns a new sub, but there's 
an extra layer of abstraction here. At the PIR or C level, currying 
could be implemented as a method on the sub object, which the internals 
of the high-level language call directly when currying is needed. That 
might actually lead to a cleaner implementation than mixing up currying 
and invocation within 'invoke'.

Allison