This will ultimately go in a more detailed version of the Roadmap,
but here's my current thinking on what comes next. Be warned, it's
written as a braindump.
Larry releases his draft language design, an overview of what will be
in the language and what it will look like. There'll be some
clarification and working out of finer points until the final release.
Then we turn this into user documentation to serve as a specification
of the language. Much of it can be cannibalised from the perl5
documentation. Roughly in parallel with this is the creation of test
cases as part of the documentation. Rather than have all this done by
large numbers of people, I want to fragment and parallelise the
development as much as possible: there'll be a pool of functions and
operations to describe, anyone interested can claim something to
document or write test cases for can do so, and there'll be a mailing
list for questions on Big Things ("can I bless a curried function?",
something I'm *sure* Damian has already written a paper on :-)
Once we have our language spec and test cases down, we have our
stopping conditions. We'll know our interpreter is working when it
passes those test cases. We'll also have boundaries for development
so we don't get carried away with new features.
Then Dan and a couple of others with lots of perl experience come up
with a set of modules that will comprise the interpreter. Then we
come up with an API. I'm thinking: assign one person to each module
and have them negotiate with each other.
Once we have an API, we write test cases to exercise the API.
Then we code.
Somewhere before coding will come the development of PIL (if we need
it). I haven't given that any thought yet, other than "we will have
to do it, but I don't know when or how" :-).
Also undiscussed are larger architecture issues like:
* apidoc
* the host faking magic required to fake fork on win32
* Unicode
I suspect this means there's a stage like "interpreter requirements"
that I haven't listed, where we say what we expect from the C code
we're going to write. This will inform the module design and
ultimately the coding.
We're lucky to have the experience of Chip to draw upon (he's already
blazed some of the trails we'll be turning into fully-paved four-lane
highways with Waffle Houses and Conocos), as well as a lot of people
who've worked with perl5. They know what works and what doesn't,
and experience is going to be invaluable in something as complicated
as a Perl interpreter.
Nat
