Durable specifications
Aug 12th, 2009 by james
Eddie has just committed code that makes Ginger self hosting once more. The last time Ginger was self hosting was when the target language was Gambit Scheme. Now the target language is c (or specifically gcc) which is, by comparison, far more foreign. At the same time, Ginger has come a long way and I have been thinking more about making a first public release. My intention is that Ginger should change very little after “1.0″. Ginger intends to act like a lisp “microkernel” providing core language functionality while delegating most functions and macros to libraries. My hope is that the Ginger libraries and their APIs will evolve and change but that changes in the Ginger core will be limited to improvements in optimizing and generating code. The result of such a dichotomy might be that while Ginger 5.0 may look a lot different from Ginger 1.0, it can still compile Ginger 1.0 programs by using the 1.0 libraries. Doing this sort of thing unfortunately involves some crystal balls and tea leaves and may not ultimately work but the stability of the core of Scheme through the R*RS series of specifications gives me some hope that by putting a lot of thought into specifications one can make durable specifications.
For these reasons, while I’m antsy to make a public release I really don’t want to call that release “1.0″. Ginger simply isn’t that mature as a specification. What more is left? My short list of core features that still need to be implemented include:
- BigNum Support
- Concurrency
- Contracts
- Macros
- Modules
- Object message passing
- Optimizations for recursion, inferred types
Despite the length of that list, Ginger is getting to the point where it is usable (at least for the adventurous) so I think I will start a series of public developer releases. The first release, DR1, will essentially be version 0.1 and DR2 will be version 0.2, etc. Any promise of stability is null and void for the DR series. Here be dragons.