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 it. 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 person). 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 will. Stevan
