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!!!!!!!!!!!
pgpkySSgvyN4A.pgp
Description: PGP signature
