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
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev