Perl6/Parrot and Backwards Compatability
Milscvaer
Hello,
I believe it would be a very good idea and quite
essential, if Perl6 is not simply a superset of Perl5
and thus by default back compatable with Perl5, for
Parrot/Perl6 to also contain complete, 100% backwards
compatability capability with perl5 code, either in a
seperate perl5 parser distributed with perl6 or built
into the perl6 parser. Perl5 code and all of the perl5
language should be able to run on parrot with no
modifications.
Furthermore, on parrot, modules written in perl 6
should be accessible
from perl5 (forward compatability), and perl5 modules
should be
accessible from perl6 (backward compatability). The
symbol spaces and so on
so on for Perl5 libraries should be accessible as
well from Perl6 and
vice versa, as they are now from one perl5 module to
another. This is
absolutely essential since there is a very large
library of existing
Perl5 libraries and it would be completely
unreasonable to expect
all of these to be converted to Perl6, if such would
be required. There are
alot of us furthermore who like the Perl5 language as
it is, quirks
and all, and want to continue to be able to use perl5
yet also have
access to new libraries written with perl6. perl6
programmers will
want to have access to modules written with perl5.
Programmers should
be able to use both perl5 and perl6 in the same
program. Those who
like Perl5 as it is should have the freedom to be
able to continue to
use it on Parrot and have a 100% perl5 compatable
language.
Every quirk and feature of perl5 really needs be
supported in the perl5
support on parrot, as I code I have written really
does depend on all of them.
Furthermore, it is very important as well that
compatabality with the Perl5
internals and XS be maintained on Parrot/Perl6. This
is to allow Perl
modules for Perl5 to be used from Perl6 programs and
on Parrot. If Parrot internals and XS
use a different API from the Perl5 ones, then a
compatability layer must be
provided to allow Perl 5 XS programs to be compiled
and run for Parrot.
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
unneeded and
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
person.
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
with Parrot.
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
other languages
loaded onto Parrot.
Sincerely,
U. Ruirarchzatrea
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
Matthew Walton
things. There is a project (Ponie) to make Perl 5 run on Parrot, and
there will be other languages as well - which will be able to call each
others libraries. Making the Perl 5 libraries available to Perl 6 being
a primary motivation. I'm not sure about how well XS will work on Ponie,
but I assume that it will be made to work if at all possible.
Brent 'Dax' Royal-Gordon
> I suggest you read more about Parrot... it's designed to allow these
> things. There is a project (Ponie) to make Perl 5 run on Parrot, and
> there will be other languages as well - which will be able to call each
> others libraries. Making the Perl 5 libraries available to Perl 6 being
> a primary motivation. I'm not sure about how well XS will work on Ponie,
> but I assume that it will be made to work if at all possible.
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.
Luke Palmer
> 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).
All your wishes up to this point in the message will come true[1].
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
not.
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[2].
Luke
[1] 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?
[2] Unless you find a way around it and tell us.
Milscvaer
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
compatability.
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.
www.yahoo.com