On Sun, Feb 10, 2013 at 3:03 PM, Gerhard R. <gerd.r.de...@googlemail.com> wrote: > On Sun, Feb 10, 2013 at 12:13 AM, Allison Randal <alli...@parrot.org> wrote: >> >> [...] But, it has all the baggage of project legacy, reputation, and >> relations >> >> with other projects, without the advantages of existing code. > > > Publicity wise, it's all in how you spin it: 'Parrot: Resurrection' has a > nice ring to it ;). As far as relations with other projects go (we're > talking about Rakudo here, right?) - there might have been a bit of > badmouthing on IRC, twitter and reddit, but that's ok as long as the people > who matter remain reasonable. > > >> >> [...] Yet another grand plan for the architecture is no better >> >> than what we have, if it isn't executed. This isn't an academic >> exercise, we don't get points for thinking about cool things. The only >> measure of success that matters is real use in the real world, and >> Parrot (and Rakudo, and Perl 6) have so far utterly failed by that >> standard [...] > > > 13 years ago, no one knew what Perl6 would look like and require in terms of > VM primitives. Now we do. > > >> >> Your quick notes on >> https://gist.github.com/gerdr/48890726c026588535fa, sound like the exact >> same things we were saying in Parrot 6 years ago. That's not necessarily >> a bad thing, but chances are that different results will only be >> achieved by setting different goals and meeting them with different >> strategies. > > > As far as I remember, Lorito/m0 design never went beyond 'This is our new > runcore and bytecode. By magic and pixy dust, it integrates with the > existing infrastructure'.
For what it's worth, there was >almost< a M1 compiler (targeting M0) with C-like syntax that actually ran. A few (2?) interested people could fix this I'd say. A good start for Parrot2. kjs We need to start with NQP's needs (6model, QAST, > regex, serialization) and come up with a good story from that end. 6 years > ago, Rakudo internals were in no shape to do this. > > >> This plan requires substantial buy-in from Rakudo, which they've been >> hesitant to give. Maybe they've just been burned in the past, and would >> gain enthusiasm as their needs were met. That's a big "Maybe" with a lot >> riding on it. > > > I don't really see that problem. The main point of the Rakudo devs is that > they don't want to work on or maintain a codebase that has yet to prove its > worth. I can't image that they would have anything against someone else > doing it. > > >> [...] I agree with Brian's comment that focusing on just "Parrot-light" >> has a >> >> better chance of success than trying to do both that and a re-design on >> the "big VM". > > > See my reply to Brian. > > -- gerdr > > > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
