You are looking at historical revision 31273 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:

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.

Replacing SRFI-14 with cset implementation from irregex?

This has been discussed ages ago. It might be more memory-friendly and performant. One problem with the current SRFI-14 module is that it assumes Latin1 encoding (and therefore can only handle 256 different characters), whereas most other CHICKEN components and eggs assume UTF-8.

Refactoring the CHICKEN test suite to use a core library?

As we remove a lot of cruft from core which it doesn't need, it may be a good idea to add some things that we do need. Like the test egg: there is a lot of macro code duplication in core's test suite. It's probably better to ship a well-designed testing library with core, which core itself can also use. This would make it easier, if we decide to do this later, to format test output on Salmonella in a consistent manner for both core and eggs.

Proposed libraries

Let's follow R7RS for these:

What will we do with the SRFIs we implement? It would make sense to define the following, but it would be tedious to import all these:

srfi-2
and-let*
srfi-8
receive
srfi-31
rec
srfi-26
cut, cute
srfi-15
fluid-let
srfi-17
setter, getter-with-setter
srfi-10
define-reader-ctor

Also, is it srfi-2 or srfi.2? The latter would match up with (srfi 2) usage which is reserved by R7RS for SRFIs.

The list below is just a proposal, can be changed at any time. We should also keep an eye on R7RS WG2, which may define a few things CHICKEN currently defines already.

chicken.modules
module, import, export, reexport, define-interface, module-environment, functor, use
chicken.types
:, the, assume, define-type, define-specialization, compiler-typecase
chicken.reader-extensions
set-read-syntax!, set-sharp-read-syntax!, set-parameterized-read-syntax!, copy-read-table, current-read-table (perhaps re-export define-reader-ctor?)
chicken.fx (or chicken.fixnum?)
fx+, fx-, fx/, fx*, fx<, fx<=, fx=, fx>, fx>=, fxand, fxeven?, fxior, fxmax, fxmin, fxmod, fxneg, fxnot, fxodd?, fxshl, fxshr, fxxor, fixnum-bits(?), fixnum-precision, most-positive-fixnum, most-negative-fixnum, fixnum-bits, fixnum-precision, fixnum?
chicken.fp (or chicken.flonum?)
fp+, fp-, fp/, fp*, fp<, fp<=, fp=, fp>, fp>=, fpfloor, fpceiling, fptruncate, fpround, fpsin, fpcos, fptan, fpasin, fpacos, fpatan, fpatan2 (?), fplog, fpexp, fpexpt, fpsqrt, fpabs, fpinteger?, maximum-flonum, minimum-flonum, flonum-radix, flonum-epsilon, flonum-precision, flonum-decimal-precision, flonum-maximum-exponent, flonum-minimum-exponent, flonum-maximum-decimal-exponent, flonum-minimum-decimal-exponent, flonum?
chicken.syntax
er-macro-transformer, ir-macro-transformer, gensym(?), expand (is this useful at all?), get-line-number, strip-syntax.
chicken.bitwise
the subset of srfi-60 we support: bit-set?, bitwise-and, bitwise-not, bitwise-ior, bitwise-xor. Possibly complete it with the remaining operations, and call it just "srfi-60"?
chicken.ports
The current stuff in ports, except for the string ports in scheme.base (also, see below). Perhaps get rid of port-fold, copy-port, port, map, port-for-each?
chicken.exceptions (or srfi-12? Would make more sense, but what about our extensions? Put those in chicken.srfi-12?)
All the exception handling stuff.
chicken.load
If we want to keep them, load-noisily, load-relative, load-library
chicken.format
[fs]?printf, format (do we need this?), pp, pretty-print, pretty-print-width

Proposed removal from core

The list below is just one hacker's idea of what could go. Please add more.

SRFIs

SRFI-1, SRFI-13, SRFI-14, SRFI-18 might be removed. SRFI-69 will be removed, as discussed in CR #1142.

queue datatype (data-structures), binary-search (data-structures), mmapped files (posix), object-evict (lolevel)

Proposal already accepted in CR #1142.

combinators

Some of the combinators from data-structures are very nice, but there only a handful of them are actually useful. There is no technical reason to keep them in core, they might fit better in an egg.

Various ill-conceived POSIX things

These things I don't like, but doesn't mean it *has* to go. It may always be put in an egg of course.

Reworking the way libraries are loaded

Right now there are just too many confusing things, like require, require-extension, use, import, load, load-library, require-library.

Units and modules are confusing also. This could just be a documentation issue.

Refactoring the scheduler

One missing ability in the scheduler is for threads to block on more than one object. This would allow us to generalise file-select to ports.

Better API for continuations

Nobody seems to use the "better API for continuations" by Feeley: continuation-graft, continuation-capture, continuation-return, continuation?

If it doesn't benefit anyone (core doesn't use it, only two eggs do: shift-reset and continuations), it can be taken out. It might be put into an egg.

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):

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.

Rewrite chicken-install and make setup-files declarative

This will make it easier to make eggs statically compilable, cross-compile them and perhaps integrate them into other build systems. It will also mean that setup-files won't be running arbitrary Scheme code as root, which means it's more trustworthy.

Another thing we need is to make files installed by eggs more explicitly registered: currently "chicken-uninstall" will simply remove all libraries that have the given name as a prefix.