Friends,
I'm happy to report that the Timber compiler is now in a such a state
that I believe it's time to switch focus to testing. All passes are
implemented and no crucial functionality is left out.
However, very few test runs have been done up to this point, which
means that we are still far from having a running compiler. The run-
time system also haven't been checked in yet, but it will be in a day
or two. Still I'd be happy for some help producing dry-run test
examples at this stage, before we risk getting stuck with issues that
relate to I/O and Unix interfacing.
My suggestion is that we split the testing activities into two phases:
1. Random testing of everyone's favorite code snippets. First goal
is to produce C output only, then in a few days also to make them
run. This is likely to draw attention to many of the (no doubt)
numerous simple and silly bugs that hinder normal operation. While
this activity might generate a lot of error reports initially it
should hopefully also lead to a relatively well-behaved compiler in a
rather short time. I expect to do most of the bug-hunting myself
while in this phase.
2. Systematic testing of all branches of every individual pass. This
should probably be combined with careful documentation, perhaps also
with writing/revising the language definition. To make this work
feasible we should split it up in some sensible way, although it's
probably wise to wait until phase 1 is over until we make an attempt
at organizing phase 2.
I also have a list of minor areas of the compiler that still need to
be completed, as well as some discussion points regarding the actual
language design. But again it's probably best to defer these issues
until we at least have a compiler that runs the basic test examples.
So if you're interested in the long term goal and prepared for some
initial disappointments, pull out the latest darcs version and
generate some error reports! Send them directly to me and I'll
respond to the list after each update to the sources.
Happy lumbering!
Johan
