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