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
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
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
> > 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
> 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
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 :)