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