On 2/7/06, chromatic <[EMAIL PROTECTED]> wrote: > 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.
Well, a few months ago I would have disagreed, but now I agree with you, by taking this down the VM level (which is that the PIL^N/PIL2 runcore is focusing on) is good "research" for eventually connecting this all to Parrot. I am glad we agree here. > > > 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. Well yes that is very true, but that was a learning process. It helped uncover some of the deficencies in the first PIL implementation (most notable the lack of OO support). It also lead to the development of the Object Space sub-project which is aiming to clarify how we get from Perl 6 to something that is executable in an environment which supports all the features designed. These are both things which the Parrot project and the Perl 6 design project did not address from what I can see. Only after going down some highly experimental paths did this reveal itself. So while I agree, they are not free to support, I would argue that they are R&D prototypes and so (to some degree) disposable, and the benefits they have brought in terms of insight into Perl 6 "the runtime" (not the language, and not the VM, but somewhere in between) are very vaulable. > 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. Exactly Yuval's point. People want something interesting enough to pique their interest, but small enough to digest for weekend/nighttime hacking sessions. If Perl 6 was broken down in such a way as he proposes, maybe it would attrack more people? or maybe it won't. Neither I or you knowt that, we can only guess. > 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. Sure that's one way to look at it, but it does not need to be that way. Reducing Perl 6 down to a core calculus like PIL actually makes it easier to target any backend you want. And the new PIL^N/PIL2 runcore will make it even easier since all that will be required will be that you create a PIL^N runtime, all the metamodel/container/boxed-type prelude will either be written in PIL^N or in Perl 6. Then the Perl 6 -> PIL2 part can be written using PGE/TGE/Parsec/whatever. IMHO this design direction (which makes multiple backends almost trivial) makes for a better more modular and decoupled design in general, which is surely a good thing for all projects involved including Parrot. > > 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. What is inappropriate about it? He is questioning the current direction of an open source project which has be regarded as many to be mearly vaporware. Sure you and I know that Perl 6 is chugging right along and making great strides, but until Pugs many people considered Perl 6 to be a joke at best, and total vaporware at worst. I think Yuval has every right to question the direction, and to make suggestions as to how he thinks it can be improved upon. He has put in time on the project, maybe not as much as others, but enough that I think he has a right to speak up if he wants. What is so wrong with that? > 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. Hmm, quite true, but I think that is mostly because the texts on the subject are so dense and there is a severe lack of hackable projects out there that people can contribute too that don't involve some esoteric language meant to explore some equally esoteric concept. However, that said, the idea of bootstrapping compilers is progressively getting more mainstream. Many of the recent languages which have sprung up for the CLR are moving towards bootstrappability. The new version of Scala is written in Scala. So maybe, as more and more people do it, they will find simple ways to accomplish that which you seem to think is so difficult. And maybe that someone will be Yuval. You never know. > 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. Your right, but you never know until you try ;) > 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. Well if it is a side effect of a modular and clean design, they it is 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. Okay, I think maybe there has been too much emphasis in this converstation based on speed of development. My concern (and I know Yuval's as well) is also with correctness, in the theoretical/mathmatical sense. Better to get it right first, then all things will follow in time. > > 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? Well modularizing it makes more digestable, thats just a given. These chunks may seem a little more complex, but IMHO they are much easier to think/reason about as seperate parts then they are as peices of a large monolothic project. > There's sort of a dearth of Scheme, CLOS, Haskell, and Scala experts in Perl 6 > development right now. Well, some are experts, some are (like me) people who want to have the cool features of Scheme/CLOS/Haskell/Scala so they are reading as much info on them as possible to try and apply that to Perl 6. > Where are they going to come from to write all this stuff? Well Pugs has either created them, or attracted them already :) Stevan
