On Mon, May 28, 2012 at 01:54:53PM -0500, B. Estrade wrote:
> 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?
For some value of "we"? Are you volunteering - I expect not. I'm not either.
In that
a) it's a resourcing problem. It's probably going to take more than one
person more than one year, full time. Or, therefore, a lot more than one
year as a spare time project.
The great thing about Parrot and subsequently the various projects that
have worked to implement Perl 6 is that they've not "stolen" existing
Perl 5 contributors. They seem to have grown the available pool of people.
It's not clear whether starting now on an "official" rewrite would be able
to do this, or whether it would reduce the (already low) number of people
working on the existing Perl 5 codebase
b) Personally, I'm not sure if it's worth it. What does it gain?
You still have all the warts of the Perl 5 language. It's a 16 to 22 year
old basic design, with at least a decade of "improvements" wedged in the
holes in the original syntax. The stuff that Perl 6 (the language) is
working to solve. Such as typeglobs (and their implications), barewords
no concept of types (other than scalar/list and
not-a-reference/reference-to-FOO), and that anything can turn out to be
tied. (Which kills your ability to JIT compile it)
It's also not clear how much of the language is actually exposing the warts
of the existing C implementation. Such as the operators that behave
differently on strings or numbers (++ and the bitwise operators)
(this behaviour change being despite the lack of real types. ie, a hack)
Then there is the "choice" of which language to implement in. The great
strength of Perl 5 is all the code on CPAN. A lot of the code on CPAN
depends on other code on CPAN, and high up many of the dependency trees are
XS modules. XS relies on talking C to the internals. And, often, that the
internals behave the current way.
So if one has a C-re-write, where is the trade off between supporting
existing XS code (and keeping the current internal uglies), and being
clean but incompatible? And if one elects to target a different VM,
such as Java or .NET
i) how much of CPAN is no longer available due to XS?
ii) how much code simply can't cope with DESTROY not happening at the
"right" time due the VM's garbage collector?
And at the end of all this, it won't completely replace the use of the
existing Perl 5 implementation, so that still needs to be maintained.
However, that's my personal view. I'm not stopping anyone else trying
(and I'm interested to see how it pans out). I'm only aware of one project
trying it, Perlito, which is working to compile Perl 5 to JavaScript:
http://perlito.org/ and https://github.com/fglock/Perlito
> That's what Ponie is/was, right?
Not quite. Ponie was an attempt to refactor the existing Perl 5 interpreter
codebase and graft it onto Parrot.
> 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.
I'd have no problem with this, but don't underestimate how much work it
is to implement any of them.
> 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
As "Perl 6 compliant" is (I think) defined by "does it run the Perl 6
spectests", you're welcome to try doing this.
I suspect that it will pass approximately zero, due to several significant
basic syntax changes between Perl 5 and Perl 6, which Perl 5 isn't ever
going to be able to adopt. Specifically
1) Sigal invariance: $hash{key} vs %hash{key}
2) No need for parens with constructions such as if(...) {...}
3) Ternary operator: ? : vs ?? !!
4) Method dispatch: -> vs .
5) Concatenation: . vs ~
> 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.
Agree - there's no need to use Parrot. Pugs didn't. Niecza doesn't.
And Rakudo is closing in on being able to target "not just Parrot"
(qbootstrap done - yay, QAST to go)
> 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.
I guess I'm not totally an outsider (although I'd consider myself a Perl 6
outsider), but also I want it really badly.
Nicholas Clark
