http://www.perlmonks.org?node_id=261811


in reply to Re: Perl 6 feature that scares me the most:
in thread Perl 6 feature that scares me the most:

1. CPAN modules that will not work with Perl 6/Parrot.
While this is not likely to be true at launch, within a year or so Parrot should be happy to load Perl5 code therefore making the majority (if not the entirety, depending on how XS dependant modules are handled) of CPAN available to Perl6.
2. It seems that everyone is writing their very own VM these days (ex: java, .net, mono, parrot), which will (of course) run faster, better, etc than everyone elses. There is hardly a practical technical incentive (platform dependency excluded) to choose one VM over the other. Parrot will be just one in the crowd.
For the reasoning behind Parrot as YAVMI1 see Elian's (Perl|python|Ruby) on (.NET|JVM), (closures) The reason for Parrot, part 2 and Why not a Lisp (or Scheme) VM for Parrot?.
4. Will not appeal to perl programmers because it will probably be bigger, require more typing, run slower than perl 5.
Slower than perl5? To quote the man himself - Parrot is an order of magnitude faster than perl 5 doing equivalent things. Without enabling any extraordinary measures. (see. Now I know how the Lisp folks feel).
5. They are not really thinking about making extending/embedding easier than XS.
Parrot won't use XS, so this is a non-issue.
HTH

_________
broquaint

1 Yet Another Virtual Machine Implementation

Replies are listed 'Best First'.
Re: Re: Re: Perl 6 feature that scares me the most:
by Anonymous Monk on May 30, 2003 at 13:16 UTC
    While this is not likely to be true at launch, within a year or so Parrot should be happy to load Perl5 code therefore making the majority (if not the entirety, depending on how XS dependant modules are handled) of CPAN available to Perl6.

    Implementing that is definitely not trivial. I think it is more likely that they will end up providing *some* support for XS modules, with the recommendation that we use the new system. Some will not be able to rely upon this emulation layer and it will not move to perl6 until they are really motivated. Continuations and closures alone, won't cut it. If it were so, all those proprietary, never seen by CPAN but running in production environments XS modules, were written in Lisp/Scheme by now

      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...

        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