Hi Boston.pm,
I'm unsure whether this draft will actually get sent out,
or to where, but since several people have asked about it,
I thought I'd post it here for feedback.
Comments encouraged.
Thanks,
Mitchell
(pedagogic puppet platypi)++
Perl 6 project Elf - 2009 Q1 status report
Summary
-------
Elf's purpose is to permit Perl 6 implementation development _in Perl 6_.
Elf is a fast, small, flexible and modular Perl 6 compiler, currently
implementing a limited ruby-like subset of p6. It is largely written in p6,
and is self-compiling.
In 2009 Q1,
() Elf development continued to slow, down to a small fraction of an FTE.
Still only one developer. There's been almost no community interest.
() Development focused on getting the rx_on_re regex engine able to run
Larry's STD.pm P6 grammar directly, mostly to attract developers with
a frontend bootstrap. 'say 3' works, but for bootstrap, the rx_on_re
runtime may need to be reworked.
() The Common Lisp backend now supports Clozure. Much quieter than SBCL.
() The frontend which uses Larry's STD.pm/gimme5 parser, has forked it,
lacking the resources to stay in sync.
() There's been little or no contribution to STD.pm this quarter.
() There's been no new elf version - elf_h remains the "active" version.
The future of elf is unclear.
Why Perl 6 matters
------------------
"Why Perl 6 matters" is more than a post in itself. But briefly, I don't
care whether perl dies or not. However,
A set of desirable programming language features will become available
to you, in whatever language you use, *years* earlier, if Perl 6 exists
to serve as foil, motivator and forcing factor.
For example, we've been waiting more than 20+ bloody years for Common Lisp's
multiple dispatch to become more widely available. It almost, but not
quite,
made it into Javascript last year. It will probably take another language
generation, and several years, for you to finally have it. Even further out
are MOPs, strong but optional typing, good object compilation without
sacrificing runtime mutability, flexible parsing, etc. And that's just from
Common Lisp.
Years ago there was the line "Perl 6 is the means by which Haskell will
take over the world". But it could of as well been said of Common Lisp.
Or of ideas from Scheme, Icon, Scala, Slate, etc.
Perl 6 is uniquely positioned to get programming languages "unstuck".
To finally get the shoemaker's children some shoes. The still large
perl community gives it the potential to quickly become a mainstream
language. Perl 6's flexible parser, compiler story, and object system,
with Perl's ecumenical culture, make it a potentially great place for
language implementation and evolution. It's willingness to accept
ugliness, sharp edges, and performance hits, when that's the price of
expressive power, may make it a challenging place to live in directly,
and hell to implement, but also makes it, potentially, an outstanding
foundation on which to build.
{ use Lisp::Arc; ... } { use Scala; ... } { use Ruby:ver<1.8.6>; ... }
"So what?" I sometimes get asked. "I've got my Haskell or CL, it's great,
who cares about others losing?". Or "I've got a language I like, and a
community I like, and sure it doesn't have some features other languages
have, but who cares?". My response is two fold. One, that there are many
potentially fun application domains whose great complexity demands a large
empowered community, not merely a small one, or individual effort. And one
with better tools than we have now. And two, that 300 thousand kids will
be born today. 2+ million this week. In 6 years they all hit primary
school. And those schools really suck. You've got 6 years to change that.
So there are important things that, as a profession and a society, we are
failing to do, in part because our tools remain so crippled and crippling.
Why Elf?
--------
Since pugs mothballed several years ago, Perl 6 implementation has been
characterized by a dearth of developers. There are several reasons for it,
but the lack of implementation development resources has been the defining
factor of the Perl 6 endeavor for several years now. The perl community
has just not meshed in the way that, for instance, the ruby and python
communities have.
When attempting to create a Perl6-class language, the obvious thing to do
is to build on an existing strong language. But pugs failed to attract
enough Haskell-writing developers, and Common Lisp, OCaml, etc, seem
unlikely
to fare better. One can work bottom up from C, via a vm (as rakudo does)
or an object system core (as smop), but it's very much harder.
Elf is based on the hypothesis that developers could be found if the
implementation language was itself Perl 6. Pugs had something like 50
active developers at one point. So, the idea was, create the first usable
partial implementation of Perl 6, write it in Perl 6, and people will flesh
it out and/or bootstrap off it.
Last year, elf became the first partial implementation of Perl 6 usable for
a non-small p6 project. Something pugs didn't manage, and rakudo/parrot is
still working towards. Usable for elf itself. Albeit not well advertised.
So far... no developers.
Alternatives to Elf
-------------------
Elf isn't the only way one might consider bootstrapping a Perl 6 compiler.
() Pugs. Despite several years of mothballs, pugs might still be the best
all around Perl 6 implementation. A lot of people succeeded in writing
small p6 projects with it. But experience is also that it cannot be used
for non-small projects - you get bogged down in implementation bugs. And
it's mothballed.
() Rakudo/Parrot. Development has focused on low-level feature coverage.
Only recently has it become possible to write parts of the implementation
in p6, for reasons both technical and philosophical. Rakudo continues to
struggle with Parrot implementation difficulties. People are increasingly
writing small p6 projects with it, but there's not yet much track-record to
suggest how well a non-small p6 project might fare, and there are several
known limitations, including performance. But it has developers.
() STD.pm-based perl5. Larry has now written a P6 grammar STD.pm, and a p5
engine which runs it. Since even before pugs mothballed, the lack of
anything which could parse p6 and provide a full parse tree, has been a p6
project blocker. STD/gimme5 and STD/viv remove this blocker, permitting
implementation bootstraps. For instance, elf would now be *much* easier to
start than it was a year ago. Elf and mildew/smop are the only existing
attempts to extend the parser into an implementation. But there's a third
approach possible. Build out STD/viv into a perl5 and Moose based
implementation of Perl 6. STD.pm itself seems headed in that direction.
Other than elf, this seems to me the most attractive near-term path towards
bootstrap.
Bigger picture
--------------
This too could be a separate post, but here's a rough sketch of "the big
picture".
Perl 6 is an evolving spec, not a particular implementation.
The different implementations have different short-term strengths and
weaknesses, different needs, different long-term risks and potential. But
it's all part of the Perl 6 effort, and all tackling a piece of the puzzle.
With all current implementations, you will have to restrict your Perl 6 to
avoid implementation limitations, and to work around implementation bugs.
Depending on your interests and skills, there are different places to help.
Rakudo is best for playing with language fragments. Currently rakudo,
perhaps pugs, and elf, for writing modules. Rakudo is a good place to
start by default.
You can currently write standard library (aka "setting" formerly aka
"prelude") code for rakudo, elf, and mildew/smop. They need quite
different code, but that's fine. There's a vast difference between "X has
been written for one", and "X hasn't been written for any yet". It's easy
enough to port from the one. So choose one, and push back the darkness.
Core OO issues are perhaps best explored with mildew/smop, though the elf
Common Lisp backend awaits someone to push it in a similar direction.
STD.pm is the best place to work on Perl 6 parsing.
Elf is the best place for non-small projects, ones with 10's of classes,
order thousand of lines of code.
Rakudo/parrot and smop need C hackers.
Perl5 runtime support for Perl 6 is can be explored with STD/viv, elf, or
Moose. Elf could really use a good p5 multimethod dispatch module.
Alternate backends, eg Javascript, could be done on elf or STD/viv.
The test suite needs, in my estimation, to grow by >10x.
And needs a generative testing system. Perl 5 suffers from it's lack of
sufficient testing. And Perl 6 is a much more complex language.
Compiler writers and Common Lisp hands would be appreciated on elf.
And as with any project crippled by lack of hands, there are places where
anyone, even non-programmers, can helpfully contribute.
A note of expectation management. Perl 6 implementation is crawling along
on a shoestring. A handful of developers digging through the maze of an
understaffed, big and complex bootstrap problem. Contributing tends to not
be a smooth process. Which can be quite confusing, and frustrating. But
even lending an oar, an hour or two a week, can be of value.
It's certainly possible that Perl 6 turns out to be a case of biting off
too much. Of choosing the wrong problem to work on. But its potential
payoff is high, and even the effort shapes other languages. There's a
reason Audrey was invited to give the OOPSLA keynote on pugs.
Elf links
---------
* http://perl.net.au/wiki/Elf
* http://perlcabal.org/svn/pugs/browse/misc/elf
* http://perlcabal.org/svn/pugs/browse/misc/elfish/on_lisp
* http://perlcabal.org/svn/pugs/browse/misc/elfish/elfparse
* #perl6 on irc.freenode.net
* http://perl6-projects.org/
So far, Elf has been an interesting technical exercise, but it has utterly
failed at it's primary goal, the only one that matters, of attracting
additional developers to Perl 6 implementation. I am uncertain what,
if anything, to do with it in Q2.
Mitchell Charity
_______________________________________________
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
