On Mon, May 28, 2012 at 03:38:48PM +0800, Xiao Yafeng wrote: > On Sat, May 26, 2012 at 6:34 PM, Nicholas Clark <n...@ccl4.org> wrote: > > > On Fri, May 25, 2012 at 08:44:30AM -0500, B. Estrade wrote: > > > > > > Realistically, that's not going to happen. The internals of the Perl 5 > > interpreter are not flexible enough to implement a lot of the features > > that > > Perl 6 has that Perl 5 does not. > > > > Nicholas Clark > > > > * Or Python 2 to Python 3, as far as I can tell as an outsider. > > > > > why can't we write a brand new perl5 interpreter or a better one based on > parrot VM if perl6's strength more than perl5 is just internals of the > interpreter?
That's what Ponie is/was, right? I think there is a major disconnect with providing a standard interpreter versus providing implementations of language "versions". It's less about making /usr/bin/perl (Perl 5) work on Parrot and more about providing a /usr/bin/perl6 on every machine and a chicken in every pot. In otherwords, people are more tied to the actual binary program called 'perl' than anything else. It's not about "Perl 5" vs "Perl 6", it's about either getting 'perl' as Perl 6ish as possible or introducing a new utility in /usr/bin (hence my earlier suggestion of a name change or reference imlementation/one_true_implementation^tm). How man awks or greps come on a standard system these days? More than one. I would not be against seeing various perls - eperl, zperl, 6perl, qperl, rperl, c++perl, jerl, etc. The way out is to quantify how well /usr/bin/perl "implements" the Perl 6 formalization - the level to which this is true would define how far Perl 5 is from "being" Perl 6 compliant. Of course, this would be a non-Parrot implementation. There is nothing saying Perl 6 "compliant" interpreters have to be written in Parrot; Parrot just provides an abstraction layer that allows there to be a cleaner separation between the compiler/interpreter and some of the complex things that need to be done to enable the features of Perl 6. Just throwing more out there as an "outsider", but someone who really wants very badly to have a reason and simple way to start using it for stuff. cheers, Brett > > it seems Gcc community had a similar discussion about mess of internal. > http://gcc.gnu.org/ml/gcc/2012-03/msg00263.html
