<br><br><div class="gmail_quote">On Sat, Feb 9, 2013 at 11:37 AM, Gerhard R. <span dir="ltr"><<a href="mailto:gerd.r.devel@googlemail.com" target="_blank">gerd.r.devel@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">[ ... ]<br>Assuming there's still sufficient interest, I propose the following steps as a way forward:<br><br>
  1. Fork off a Parrot-light with the sole purpose of supporting Rakudo<br>[ ... ]<br>  2. Start design of Parrot2<br>[ ... ]<br>Any comments?<br><br>-- gerdr<br><br>[1] <a href="https://gist.github.com/gerdr/48890726c026588535fa" target="_blank">https://gist.github.com/gerdr/48890726c026588535fa</a></div>
</blockquote><div><br></div><div>Since flexibility is such a big part of Perl 6 - I've made partial stabs at a REBOL / JSON+ implementation using Rakudo in the distant past - wouldn't Parrot-light be an admirable enough goal? It could be fast, it could be close to the machine, and people could confidently write their other languages in Perl 6.</div>
<div><br></div><div>It's just that Parrot has felt like its design has already been in a consistent state of flux. I got distracted a while back due to rumblings about removing PIR. I wasn't opposed to removing that layer, but I wanted to wait until the design had settled down before I got deeper into the VM. I worry that a Parrot2 would maintain the issue of design flux.</div>
<div><br></div><div>I mean, unless "Parrot2" is just "super awesome Parrot-light."</div></div><br><div>Kind Regards,</div><div>Brian Wisti - a random geek</div><div><a href="http://coolnamehere.com" target="_blank">http://coolnamehere.com</a></div>