On Tuesday 07 February 2006 15:56, Stevan Little wrote: > The Pugs project and the Parrot project have had very different goals > actually (at least Pugs did from the early days). Pugs aimed to be > able to evaluate Perl 6 code, as a way of testing the language > features and design. It did not really attempt (until the PIL work > began) to provide a VM for Perl 6 to run on.
In my mind, that's the most valuable thing Pugs could do. > And even the PIL work began as a way to strip Perl 6 down to a more > managable core calculus which was easier to interpret, the multiple backends > seemed to grow out of that as a side-effect. But they're not free to support. Now I'm not arguing that the existence of multiple backends takes effort away from a single unified backend. This is open development. People work on what they want to work on. Still, finding the greatest common factor of features between LLVM, Scheme, Spidermonkey, classic Pugs, Parrot, the CLR, the JVM, Perl 5, and whatever other VM is out there means pushing a lot of things up the implementation stack. > Much of what Yuval is proposing is ways to fill that hole and to > decompose and refactor the current Perl 6 development process so that > we can have a real production Perl 6 to play with that much sooner. I agree that that's his goal. I disagree on its appropriateness. There are people who can write a bootstrapping compiler from the top down in such a way that normal people can write the user-level primitives in that language. I've met those people. I'm not one of them. There are precious few of them for any language, much less Perl 6. It's not fast. It's not free. It's not clear that they'll suddenly appear to do this work if there's a comprehensive, intelligible rework of the Perl 6 plan. I could be wrong and if Yuval writes the plan and it works, great! I'm happy to be wrong. > But also have a Perl 6 that some PhD canidate can re-write the > type-checker for his thesis project or that some volunteer hobbiest > can re-implement the core in FORTH or some open source hacker can hack > the circular prelude to make the Schwartzian transformation that much > quicker and efficient. Again, I can see the theoretical benefit to that, but it's still not free. The well-worn adage is "Good, fast, or cheap -- pick two." Perl 6 development right now is cheap but hopefully good. Reducing the goodness might make it faster. Reducing the cheapness might too. I think the real problem is somewhere in there. > IMHO breaking down the project into smaller more digestable chunks > carries as much risk of failure as putting all the eggs into single > Parrot nest. Exactly how is Yuval's proposal making the chunks more digestible? There's sort of a dearth of Scheme, CLOS, Haskell, and Scala experts in Perl 6 development right now. Where are they going to come from to write all this stuff? -- c
