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 


> it seems Gcc community had a similar discussion about mess of internal.
> http://gcc.gnu.org/ml/gcc/2012-03/msg00263.html

Reply via email to