At 9:58 AM -0500 6/25/02, Dave Goehrig wrote:
>On Tue, Jun 25, 2002 at 09:42:50AM -0500, Dan Sugalski wrote:
>> That'd be cool. Be aware that Parrot, at the moment, has *no*
>> extension API at the moment.
>
>Well the bigger problem for the XS compat layer will be the utter
>lack of perl5 STASHes and GVs. The namespace games are just going
>to have to be faked for the moment.
Some of the namespace games, yes. Not huge numbers of them--aliasing
single variables is straightforward enough. I don't think most
extensions really do anything fancy with globs.
>For the actual call interface, it should be possible to fake the
>perl5 arg stack with Parrot data structures. And that's what I'm
>going to focus on primarily.
>
>> (None of the functions, save those explicitly exported
>> in the embedding code, will be visible externally)
>
>Well we can always dream :)
Yeah, dream about typing properly. :) I *meant* "None of the
functions, save those explicitly exported in the extension code, will
be visible externally."
>Seriously though, both python and ruby have excellent extension
>mechanisms, and allow you to see a lot of the internals.
>The thing is one can write an extension to Python with only knowing
>a handfull of functions, and so the urge to build such monsterous
>things is less strong.
Yeah, I know. I'm trying to skate the line between exposing the
semantics of the internals and the actual internals. Most of what
perl 5's engine does *semantically* is perfectly fine, it's just
(well, mostly) the API that is horrid. What I want to do with Parrot
is separate the API from the internals as much as possible, so that
we can change the way the internals work without forcing a major
change (like the one we're facing going from 5 to 6) on the
extensions.
Might not happen, but I'm trying.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
