|Perl: the Markov chain saw|
Re^2: YAP6: A p5 approach to p6by chromatic (Archbishop)
|on Dec 24, 2007 at 20:12 UTC||Need Help??|
... why was the original decision made to implement Perl 6 with something fancy like Parrot instead of a simpler approach like YAP6 takes?
The people who started Parrot had a lot of experience working on the internals of Perl 5 and knew what it would take to support the features that Perl 6 needed in Perl 5: several miracles and tens of megabytes of compressed diffs to rewrite nearly all of the guts of Perl 5.
Take just one feature, for example: B::Bytecode. That's never worked reliably in Perl 5, and Perl 6 strongly suggests that it should work. The corresponding feature has worked in Parrot for years. No one's hacked on the version in Perl 5 for years, and that's not because it's impossible to work on, but no one with the knowledge to make it work has wanted to make it work.
Could Perl 6 have gotten here (or could it get here) faster if a simpler plan for the implementation had been chosen?
... it could be dropped in favor of a simpler Perl 5 -style approach...
Did you intend to call Perl 5's internals simple? It's not clear to me how to implement several features of Perl 6 in an efficient fashion on top of Perl 5, including: reflection, method dispatch and redispatch, parallelism, junctions, concurrency, asynchronous IO, continuations, pervasive closures, and modifiable grammars.
That doesn't mean it's not possible at all, nor that it's not possible to do such things efficiently, but it's my opinion targeting Perl 5 as a VM would, if it had even worked by now, have resulted in a very stripped down Perl 6 with a feature set roughly on par with Perl 5 right now running much more slowly than Perl 5.
If instead you meant to ask "Why not target an existing virtual machine?" then please see the Parrot FAQ.
Update: Upon re-reading, I realize you may have asked "Why build a generic virtual machine optimized for handling dynamic languages (Parrot) instead of a specific virtual machine optimized for handling Perl 6?" That's a slightly different question.
I suspect but can't prove right now that if YAP6 evolves to be able to handle all of Perl 6, it will resemble Parrot in a lot of ways. It may be simpler in some ways because it avoids some of the customization points necessary to run other languages, but there really aren't that many; Perl 6 is a superset of a lot of language features, and it offers a lot of customization internally to mutate the language into plenty of pidgins.