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.
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.
> 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.
Matthew Walton <matt...@alledora.co.uk> wrote: > 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
Milscvaer writes: > 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?
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.
> Milscvaer writes: > > 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.
__________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com
|
