CHICKEN 6 roadmap

  1. CHICKEN 6 roadmap
    1. Full Unicode support [implemented]
    2. R7RS support [mostly implemented]
    3. Windows support
    4. Current status

Here's a proposed list of things we would like to see in CHICKEN 6. 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!

Full Unicode support [implemented]

As described in UNICODE transition full support for extended character sets will be added. This includes several API changes, a bytevector module and a few incompatibilites that are deemed necessary for a clean integration.

These changes to the runtime system have been implemented and undergo testing. Due to the nature of the changed internal string representation and differences that are caused by the stronger distinction between textual strings and other byte sequences, a number of incompatibilities to CHICKEN 5 will have to be taken into account, which, in my opinion, are necessary and can not be prevented.

R7RS support [mostly implemented]

The r7rs egg has been integrated into the core system. All (scheme ...) modules specified by R7RS are available for user code. For easing the porting of existing code, the scheme module still refers to R5RS Scheme and is an alias for R7RS' (scheme r5rs) library module. Toplevel code outside of any module still defaults to R5RS, just enter

 (import (scheme base))

to have an R7RS-compliant environment.

The current list of changes can be seen here.

Windows support

A recurring question. We have little resources and keeping the support for various toolchains is a challenge and adds a lot of complexity. Possible approaches would be to concentrate on a single toolchain or simply require WSL2 and drop special support completely.

--- Chicken is one of the few Schemes that can deliver a standalone (static) or nearly standalone (executable + DLLs) programs, and that is an important capability. Users are used to copying EXE files or unzipping archives or (especially) running installers. Asking them to install WSL2 *as an execution environment* is too big an ask. That said, I think it would be fine to abandon all toolchains except mingw64. Of course, MSVC would be even better, but obvs we don't have that capability. (jcowan)

(Note that Cygwin support can stay, as the differences are not too big.)

Current status

The UTF- and R7RS support has been mostly implemented and is available in the git branch utf+r7rs. To build the system from scratch, there are currently two bootstrapping steps involved (sorry):

The reason this is currently so involved is that there are two internal changes that influence the generated code: the internal string representation (for UTF) and the changes to what modules export which identifiers. These changes require to build chicken compilers with successively added extensions and modifications, otherwise you will end up with an unbuildable system.