Re: Re: Re: Re: Perl 6 feature that scares me the most:

[Elian]

You're right, a not insignificant chunk of the XS code won't be able to be build under parrot, no matter what we do. We haven't (yet) sat down and gone through the perl 5 API to see what can and can't be thunked to work on Parrot.

Some of it, certainly, can be done with simple macros. Stuff like SvIV or newSViv is a no-brainer, and we will do those. Things like the array and hash access are trickier, but we can probably manage those as well.

Where it becomes less trivial is with things like SAVETMPS and magic, and I'm not sure what we're going to be able to do for that. When we figure it out we may well put together a consistent transition API for both perl 5 and parrot, so people who are interested in moving over can migrate to the transition API as they get time and interest, so their code will require even fewer changes to build on Parrot...

[tye]

People who follow my XS philosophy (write as little XS as possible, don't write "Perl in C", pretend you are using Inline::C not XS, have a Perl wrapper make the data C-friendly for the XS routine if needed) probably won't have to rewrite.

I just wanted to "gloat" since I think I get more "disrespect" for this philosophy than not. (:

Update: You can do more than wrappers, just deal with data in C-friendly structures in your C code; don't write C code to manipulate Perl data structures.

                - tye

[Elian]

Absolutely--the people who are only writing wrapper code won't have nearly so much to worry about... <ducking>