Dan,
I've started work on a XS wrapper extension for Parrot, and have been spending
a lot of time looking the current Perl5 API relative to Python's and Ruby's.
I am working under the assumption that the Parrot extension API will have
a minimum of the following parts:
1.) Data creation function having both of the following properties:
a.) Create & register new PMCs
b.) Toggle GC on/off
say with the following API for sake of arugment:
let TYPE be either a char* or an enum
PMC* parrot_wrap( TYPE , void* pmc, size_t size, bool copy );
PMC* parrot_new( TYPE );
2.) Subroutine invocation facility having either:
a.) an op "callxs I1, P1",
which calls a function with prototype:
PMC* (*I1)(PMC *P1);
b.) a XSUB PMC* with a "call" method which calls a function
with the prototype:
PMC* (*)(PMC *XSUB, PMC *ARGS);
c.) a wrapper method to invoke the PMC's methods, so after
we call new, we can actually set the PMC's data
and manipulate it.
3.) Hook functions for registering PMCs & functions with
an environment / namespace support subsystem:
a.) bool parrot_bind ( char *name, PMC *data );
c.) bool parrot_bind ( char *name, PMC* (*func)(PMC*,PMC*) );
d.) PMC* parrot_lookup ( char *name );
I feel that section 1 is a fairly safe assumption to make, maybe not on
the actual prototypes, but the functionality. I based the sample API
loosely on Ruby's structure/object wrapping system. It should be able
to replace perl5's newSV*, newAV, newHV, and some aspects of sv_2mortal.
Section 2 is obviously a bit of fancy, and draws inspiration from Python's
API. The assumptions are that a new op would be useful for all Parrot's
calls to external functions would be useful, and that all Parrot extension
functions will have a common prototype. Since PMCs are rather OO, I supplied
my best guess for the most natural prototype. The function returns a PMC*
containing the return value of the function and is passed two PMCs, the first
a XSUB PMC describing the current calling context, and the second is a PMC
which contains the array or tuple of arguments. You can possibly remove the
XSUB context arg, but you then have to expose more of the internals to
extension writers. I'd like to suggest that a PMC is a good way of providing
the interface to the internals an XS writer needs.
And finally section 3 is what we need to replace all of the GV related calls,
and those perl5 extensions which acquire SV* AV* and HV* by name. These
are basically hook functions, which would in part pass upwards to some sort
of language specific namespace mangler routine at the Parser level.
If we get this much of an extension API, we should be able to reimplement
most of the core XS functions in a very Parrot native way. Since current
XS code returns values on the call stack, the proposed solution simply
returns the mangled arugment array as the return value of the XS. That
is to say, we treat the argument array passed to the proposed Parrot
as the perl5 call stack, and return the processed call stack as the
wrapped XS call's return value. Simple no?
--
David J. Goehrig [EMAIL PROTECTED]
All reports, excluding those of historical fact, may be considered speculative.
- a faceless Compaq disclaimer
