Apologies if this is insulting to anyone, but personally I think that Perl 6 (pugs, parrot, everything) is losing too much momentum lately. I think we need to seriously rethink some of the implementation plan.
The required points of emphasis which I think are slipping out of our fingers are: code reuse, KISS (on the implementation level). On the positive side I would like to say that despite my criciticism I think the Perl 6 community has accomplished a great deal in the last 5 years, and an especially great deal in the last year (thanks to pugs serving as a catalyst). Good work everyone! In a nutshell: Split the big task that is "Implementing Perl 6" into smaller chunks detailed herein. Why is this a problem:: Perl 6 is a very very very rich language. It's got many overlapping features (a bajillion loops, operators, yadda), many special cases (Roles, Classes, Traits - they are specializations of a similar thing), a HUGE library (access to most of the standard C library, extended math routines, routines for the builtin types, routines for higher level IO than the standard C library, etc etc etc). How can it be fixed: Split Perl 6 into layers stack, instead of mashing it all up. Perl 6 Core - a simple, concise core language in the spirit of Scala, Haskell, and all the "cool" languages today. Let's face it - they have been the most innovative languages of the last 20 years or so in terms of quality, robustness, performance, extensibility, conciseness. If we copy this we get a solid foundation. This backend is optionally type checked, contains a very bare bones object oriented system (prototype + multimethod seems to me like the most generic approach), etc. Perl 6 Extended - Using good domain specific language support (extensible grammer, string macros and core language AST macros) we implement all the syntax that makes Perl 6 an accessible language on top of the Perl 6 core. This contains the grammar for Perl 6 as defined by the synopses. Perl 6 Prelude - the builtin routines for handling internal data types, etc. These must be completely portable, and are part of the internal spec. Perl 6 Standard Library - contains chunks of stdc, POSIX/Win32 API, generalizations of IO, etc etc. This is mostly portable, but e.g. fork() will be missing on platform X, that will be missing on platform Y, etc. Perl 6 VM support - the prelude compilation ideas I tossed around several months ago relate to this - *ANY* high level function can get it's own opcode or low level replacement function if it's provided. This approach is just a simplified generalization of the opcode/internal routine pattern, in a way that can be exploited for performance, rapid development of backends, testing, having a reference implementation of the prelude and library, etc. (I will reply to this post with refernces from the past). Perl 6 Parrot support - implementing Perl 6 Core, then Perl 6 Extended, then perl 6 Prelude (mostly for performance reasons) in a way that canonical with the VM support. -- on the compiler front we can also componentize -- Parser - can parse Perl core, and have it's grammar updated from callbacks. Compiler - compiles Perl core to PIL Interpreter - interprets PIL - slow, but complete Linker - loads PIL interface files / modules and grammar extension modules, assists the compiler in disamgiuating, allows refactoring the parser extensions, and provides necessary info for the type checker. Typechecker These should be implemented in Perl 6 eventually, but not at first. Pugs is a good start, but requires lots of separation and decoupling for this to be realized. Perl 6 Core macros are just functions that accept ASTs as input, and are invoked at compile time. They are interpreter by the PIL interpreter if all else fails. Using these tools Perl 6 Extended can be bootstrapped. At the next phase we need: Generic VM Emitter - a "Base class" for implementing VM emitters that assist in matching functions to opcodes or VM specific routines. Parrot core - porting the PIL interpreter, porting bootstrap code to allow the linker to link compiled modules, bridging between PIL and PIR up to a point where PIL macros can be written in PIR, and the compiler can use the PIR backend to run compile-time PIL. Note that whenever I say "Parrot" in my opinion you can also shove "javascript", "llvm", "neko", ".net", "jvm" and whatever else in there - I think they are equally important (if not more - after all they are live, production ready targets). This plan with pugs in mind: If Audrey is willing, I think a correct new direction for pugs is to try and separate the parts even more - the prelude is a mess right now, many of it's part are duplicated across the backends, the standard library that is mashed into the prelude, and into pugs core itself, etc. After this step I think the multiple backend approach should be refactored heavily to share as much code as possible, in accordance with the plans I posted (confusingly termed Circular Prelude stuff back then, see also VM support listed above). The biggest missing component of the compiler is: self hosting grammar, "real" macro support all the way down, a linker (the groundwork for this has improved with the new lexical importing code lately), and type checking. The Perl 5 compatibility layer: an additional deprecated library that emulates the Perl 5 standard library which wasn't absorbed into Perl 6 the perl 5 to perl 6 converter Integration with Ponie to enhance code reuse Additional criticism: Right now the biggest problem in Perl 6 land is project management. We, as a community, are facing a task which is sliced into chunks that are just way too big in my opinion. People burn out. People have to do things more related to day jobs (that's why my pugs hacking is on hold, for example), people think things half way, etc. If we have a layered approach we can concentrate on providing something that is more balanced ... Phew. Ciao! -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me spreads pj3Ar using 0wnage: neeyah!!!!!!!!!!!
pgpTSz073ssT9.pgp
Description: PGP signature