<?xml version="1.0" encoding="windows-1252"?>
<node id="658923" title="Re^2: YAP6: A p5 approach to p6" created="2007-12-24 15:12:22" updated="2007-12-24 10:12:22">
<type id="11">
note</type>
<author id="1382">
chromatic</author>
<data>
<field name="doctext">
&lt;blockquote&gt;&lt;em&gt;... why was the original decision made to implement Perl 6 with something fancy like Parrot instead of a simpler approach like YAP6 takes?&lt;/em&gt;&lt;/blockquote&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;Take just one feature, for example: [CPAN://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 &lt;em&gt;impossible&lt;/em&gt; to work on, but no one with the knowledge to make it work has wanted to make it work.&lt;/p&gt;

&lt;blockquote&gt;&lt;em&gt;Could Perl 6 have gotten here (or could it get here) faster if a simpler plan for the implementation had been chosen?&lt;/em&gt;&lt;/blockquote&gt;

&lt;p&gt;Who knows?&lt;/p&gt;

&lt;blockquote&gt;&lt;em&gt;... it could be dropped in favor of a simpler Perl 5 -style approach...&lt;/em&gt;&lt;/blockquote&gt;

&lt;p&gt;Did you intend to call Perl 5's internals &lt;em&gt;simple&lt;/em&gt;?  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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;If instead you meant to ask "Why not target an existing virtual machine?" then please see the &lt;a href="http://www.parrotcode.org/faq/"&gt;Parrot FAQ&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Update:&lt;/strong&gt; 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.&lt;/p&gt;

&lt;p&gt;I &lt;em&gt;suspect&lt;/em&gt; 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.&lt;/p&gt;</field>
<field name="root_node">
658902</field>
<field name="parent_node">
658917</field>
</data>
</node>
