You are looking at historical revision 31268 of this page. It may differ significantly from its current revision.

CHICKEN 5 roadmap

Here's a proposed list of things we would like to see in CHICKEN 5. Feel free to add more details if you know of a way to implement something or have an idea how to improve some part. Please, no editing flamewars here!

Modularising the compiler

There's a preliminary version of this in the compiler-modules branch. This is just an ugly first step to get the ball rolling. What remains to be done:

• Define an "official API" for users of the compiler. Basically everything that's currently being done through ugly ##compiler# hacks should have a supported, documented way to do it. Later, we can expose more features.
  • Hooks for adding new foreign types. Used by bind.
  • (possibly?) Hooks for adding new compiler literals? Used by numbers.
  • Some standard way to determine the current source file (ideally this would be a library procedure which works the same way in compiled and evaluated code). Used for things like the s48-modules egg.
  • Perhaps a way to define new compilation stages.
• Rename the compiler modules to a single namespace. Right now it uses generic names like "optimizer" and "compiler", which might be re-used by user code, and thus might give a namespace collision, even (especially?) if we do not expose the import library for some of these parts. Perhaps simply prefix them "chicken-" or "chicken.". The latter would play nice with the r7rs module system; you could import it as (chicken compiler) there, for example.

Reworking the core modules ("units")

Right now the modules supplied by core are somewhat arbitrarily named, and too many unrelated things are grouped together. We should go through the system and look at what we have, then make logical names. Suggestion to appear later on this page, for further discussion. We should attempt to align it with the r7rs naming conventions, to make things easy for that egg, and for people new to CHICKEN but familiar with other r7rs implementations. This probably means "scheme" should be renamed and split up to "scheme.base", "scheme.load", etc. A possible generalisation (or "convenience hack") could be to define the "scheme" module to import all of the underlying submodules.

Refactoring the I/O (ports) system

Currently, ports are somewhat ill-defined: they're a hand-coded record type with a bunch of slots, with comments indicating which slot is used for what. It would be cleaner and easier to understand the code if this was changed to a "proper" record type.

Recently I discovered that set-file-position! does not work on string ports. Port position should be part of the official interface, so that this is extensible, and if a port implements it, it can be rewound. This makes sense at least for file-backed ports and string ports.

This is also a good opportunity to look at why I/O is so slow.

Integrating the full numeric tower

Obvious, but a lot of work which will probably result in a long tail of fallout (issues, bugs, missing support).

Important TODOs (most of which can be done inside the numbers egg):

• Get rid of the last few malloc()/realloc() calls (for this I must (re-)study the division algorithm and hack it up further. Or reimplement it from scratch, if necessary: the current code is massively hairy)
• Figure out an acceptable C API. Right now a few things are in Scheme that might be better implemented in C. Or at least should be callable from C somehow (notably parsing numbers).
• (related to the above): Rename the C API functions to be more "CHICKENy", and get rid of all the strange S48/MIT-style C macros. This also involves using C_word at the right places, instead of "int" or "long".
• Update the FFI and other subsystems to know about the new number types, so that e.g. full 64-bit integers are mapped to bignums and vice-versa (and exception thrown if it doesn't fit the given C type).
• Add a new number-type ("smallnums?") that corresponds to the current "generic" type. Possibly add a new integer type that allows only fixnum/bignums.

Once we get around to implementing this, the main task is going through the entire C API and converting all the inline and non-allocating operations to CPS, and/or make them accept an allocation pointer.

String encoding

This at least needs some additional thought. Do we want to make UTF-8 the "official" encoding? If so, ideally, all string operations should reject invalidly encoded byte sequences (should we still allow NUL bytes to be represented?). What to do with the Unicode case folding lookup tables, string-ref?

If we go full Unicode, the SRFI-4/blob types might need some attention, because strings can no longer be (ab)used as byte vectors.