This is very important as there is a very large
library of XS modules for
Perl5 and it is totally unreasonable to require that
they all be rewritten for
Parrot to be able to be used. I know the XS interface
and the Perl5
internals can be rather ugly, and its fine if Parrot
wants to provide an
improved API, but its still important to provide a
compatability layer for
the old one in order to
allow compatability with existing modules and prevent
unreasonable amounts of work it would require, and
wasted time, to port old
modules to a new API. It would require much less work
and effort to
simply provide a compatability interface and allow
Perl5 XS modules to run
on Parrot and to be accessible from Perl6, than to
attempt to rewrite all of
the modules one would want to have access to on Perl6.
Perl5 and Perl5 XS
compatability will furthermore prevent the
fragmentation of the Perl
community into Perl5 and Perl6 camps, by assuring that
Perl5 modules can be
loaded from Perl6 and vice versa. It also assures that
the rich selection of
modules and packages avialable for Perl5 will be
immediately and instantly
avialable from Perl6, thus continueing the inertia
generated by Perl5 into
Perl6.It allows Perl5 programs to as well benefit from
new Perl6 modules, so both Perl5 and Perl6 can be a
part of the same community rather than being fractured
off into seperate communities.
One reason I use Perl is the vast collection of
modules avialable from CPAN and the choice in modules.
Perl needs to preserve avialability of all of these
modules. Remember that a module, or any feature, that
is useless to one person is essential to another
Running the old Perl5 interpretor and the Parrot in
the same process is not
a great solution, since this would mean that there
would be two completely
seperate interpretor codebases to support. A big part
of Parrot is to allow several
languages to use the same interpretor, thus allowing
them all to benefit
from the same solid foundation. It would be quite
ridiculous if Perl did not completely support a past
version of itself on Parrot given we are writing
parsers for numerous other languages for Parrot (a
good idea, indeed, but lets make sure Perl5 has a
Parrot parser too).
I urge complete 100% Perl5 support including XS and
internals to be included
This would seem to be a pretty natural feature for
Parrot, which is
designed to host several language and should also be
extended to other
languages Parrot supports, why not allow a programmer
use Parrot to
run code for all of the languages avialable on it in
one program, and
allow code in one language to call code written in
loaded onto Parrot.
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
XS modules that use the proper macros to deal with Perl 5 SVs should
work fine with Ponie. Ones that muck around in the internals of SVs,
or deal with things like the parse tree (B::*), will need to be
rewritten. (But many of those things are necessary because Parrot
does them very differently--e.g. it uses bytecode instead of executing
the parse tree directly.)
Brent 'Dax' Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
There is no cabal.
All your wishes up to this point in the message will come true.
That's what Ponie is designed to do. But the first sentence of this
paragraph is a little unsettling. Ponie runs most of the Perl 5
interpreter in Parrot (it does use as much of Parrot as it can), but I
would still say that it is its own interpreter. It's simply not
possible to run on interpreter B when all the code thinks your running
in A. It's possible some of the time, but in the general case it is
So ponie will be most of Perl 5 running in the same process as parrot.
And that's just the way it is, and there's no way around it.
 If you replace every time you said "all" with 97%. Yeah, I know
your code depends on all the quirks of Perl 5, etc., etc., but you just
can't get them all. Modules that involve perl source patches simply
won't work. But then again, those weren't really "modules", were they?
 Unless you find a way around it and tell us.
Ive thought about it and it is really perfectly fine
with me if large parts (or all) of the old perl
interpreter where bundled with Parrot in order to
provide Perl5 compatability on Parrot. If using
existing Perl5 interpretor code saves effort and works
well, but still allows you to achieve Perl5/Perl6
interoperability, go for it. Especially with XS
support, using existing Perl interpretor code could be
helpful and save effort, and provide excellent XS
As far as Perl modules that involve a patch to the
Perl intepretor, personally I am not bothered if
something like that doesnt work.
The important things is that standard XS code and all
pure perl5 code be able to run with Parrot, and
accessed from Perl6, and Perl6 modules accessed from
Perl5. When I code in Perl6, I want to be able to
still have access to the rich set of CPAN modules that
I have used with Perl5, and use new Perl6 modules from
my Perl5 programs. This would also allow Perl5 and
Perl6 to share the same module archive and allow all
of the Perl5 modules (that arent patches to the
interpretor) to be accessed from Perl6. There is a
lot of stuff and work in CPAN, and I hope the
diversity and selection of tools found their will
remain. Remember, a module (or feature) that seems
worthless to one person might be essential to another.
As a side note, it might be of interest to you, that
completely seperate interpretors have been bridged
before. Take a look at the Tcl module. It basically
runs the Tcl/Tk and Perl interpretors in the same
process, and allows you to call Tcl/Tk functions from
Perl and vice versa. Execution jumps from one
interpretor to the other, yet each interpretor is
completely seperate. I myself have gotten extensive
use of this module.
Do you Yahoo!?
Check out the new Yahoo! Front Page.