You are looking at historical revision 43009 of this page. It may differ significantly from its current revision.
CHICKEN 6 roadmap
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.
Issues
- Module (chicken base): symbol-ecape has been removed; exact-integer-sqrt?, vector-copy!, make-parameter, call/cc, open-input-string, open-output-string, get-output-string, input-port-open?, output-port-open? and port? have moved to (scheme base), the same applies to parameterize; case-lambda moved to (scheme case-lambda).
- JC: Should this be reimplemented on top of (scheme base) rather than (scheme)?
- Module (chicken platform): features moved to (scheme base) and returns a list of symbols, not keywords.
- JC: How about providing both symbols and keywords?
- Module (chicken file posix): file-read requires a byte-vector argument.
- JC: And file-write too?
- The modules r4rs, r5rs, r4rs-null and r5rs-null have been renamed to (scheme XXX).
- JC: Only r5rs should be moved to scheme.
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):
- Checkout utf-bootstrap and run make boot-chicken.
- Checkout utf+r7rs-bootstrap and run make CHICKEN=<path-to-chicken-boot-built-previously> ... and then make CHICKEN=./chicken boot-chicken (I'm not sure whether the former build step is needed, but just in case...)
- Checkout utf+r7rs and build it using make CHICKEN=<path-to-chicken-boot-built-last> ....
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.