On 2/7/06, Allison Randal <[EMAIL PROTECTED]> wrote:
> On Feb 7, 2006, at 15:31, Stevan Little wrote:
> >
> > Now I am not as involved in Parrot as I am in Pugs so I might be way
> > off base here, but from my point of view Parrot still has a long way
> > to go before it runs Perl 6 code. Part of that is because the bridge
> > between PIR/PMCs and Perl 6 just does not exist yet (either in code,
> > or even conceptually). Having PGE parse Perl 6 code only gives us an
> > AST, it does not give us running code. And even if we have a nicely
> > massaged AST, running Perl 6 is not a matter of just walking the tree
> > and evaluating it like it is in Perl 5 (of course, I am simplifying
> > quite a bit here). We found (a few months ago) in Pugs that this model
> > just isn't robust enough, and Perl 6 is going to need a more
> > sophisticated "runtime" environment to support many of it's features.
> > This "runtime" (or as we have been calling it in Pugs the "Object
> > Space") will need to exist on top of Parrot too since it is far to
> > Perl 6 specific to be implemented into the Parrot core.
> >
> > This is the kind of stuff that Yuval is talking about. The missing
> > bits that need to exist in the nether-region between perl6-language
> > and perl6-internals.
> >
> > We are building from the bottom-up (Parrot) and the top-down (Perl 6 -
> > the language) and it seems (at least to many of us on the Pugs
> > project) that there is a big hole somewhere in the middle.
> You imply here that obstacles to implementing Pugs are necessarily
> obstacles to implementing Perl 6. That's not entirely accurate.

Well, the first obstacle I see to implementing Perl 6 can be fixed
with the object space work, and I do not see the Perl 6 Object space
work as being Pugs specific at all. From work I and others have done
on the meta-model  as well as the container types, it seems clear that
we need a very robust Perl 6 runtime environment. And currently Parrot
does not provide enough of that environment. This is not to say that
Parrot *cannot*, only that it does not currently. And in my opinion,
Parrot shouldn't cater this much to Perl 6 anyway. Parrot's object
model is sufficently generic to support the object model of most of
the current crop of dynamic languages, but that will not be enough for
Perl 6. You just can't compile all the runtime dynamism into PIR and
PMCs, you will need a runtime environment (an object space) to support

The next obstacle to implementing Perl 6 I see is the
type-checker/inferencer, this is not the job of Parrot, or of PGE. It
a the job for a type inferencer, of which I don't see work on one
currently outside of Pugs and Yuval's Blondie work.

Then there is the prelude. Why write Perl 6's built-ins in PIR when
you can write it in Perl 6? Assuming the Perl 6 codegen is good enough
of course. And modern compiler and optimization technology has been
doing those things since the late-80s (there are many studies of how
compiled Ada code was faster and better than expert hand coded
asssembler, there are just some things a computer can do better than a

I think Pugs and Parrot/PGE share many more obstacles than you might think.

> But, there is another route, and we're working on it at the same
> time. From the Parrot perspective, PGE parses the source, its output
> is translated to an AST (or a couple of intermediate ASTs), and that
> is translated either to PIR, or directly to bytecode.

But this is my point, this won't be enough to support all that Perl 6
is to be. PIR & PMCs simply are not enough to have full metaclass
support, roles (at compile/class composition time, and runtime),
traits, etc. And lets not forget that (to quote Larry in S02 i think)
"Perl 6 is an OO engine". Which means that container types like
Scalars, Arrays and Hashes are objects now too. These things map
nicely to some of the current PMCs, but they are not boxed inside the
object metamodel, and until they are they are not extendable and
usable in the way the language design prescribes.

The Pugs project started out with an AST which was then evaluated,
which is similar to your AST translated to PIR, and we just found it
wasn't enough. Perl 6 is just simply to dynamic a language for that.

> I'm working on a prototype of this now in Punie, specifically so we can try 
> out the
> whole path from source code to bytecode.

I am familiar with your Punie work as I read your use.perl journal and
the Perl 6 meeting notes regularly. But IIRC Punie is a compiler for
Perl 1 is it not? Perl 1 is a very very very long way from Perl 6.

> Perl 6 will get implemented.

Oh, of that I have no doubt. Never did, and neither does Yuval (if I
may speak for him while he is asleep :). But all that we are trying to
do here is shake out some cobwebs, a little spring cleaning if you


Reply via email to