CHICKEN 6 roadmap

  1. CHICKEN 6 roadmap
    1. Full Unicode support [implemented]
    2. C code cleanups
    3. Remove the "Feathers" debugger from the core system
    4. Drop the old profiler?
    5. Windows support
    6. Moving R7RS support to the core

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.

The incompatibilities are the following:

C code cleanups

A number of historical C preprocessor definitions are used throughout the runtime system that have no use anymore, most notable C_TLS, C_externimport, C_externexport and C_fcall. These should be removed.

Remove the "Feathers" debugger from the core system

I (felix) would like to move this into an egg. It doesn't seem to be used a lot and has a number of shortcomings which I currently don't have the capacity to address. Moving it into an egg separates the maintenance and makes it easier to modify or replace.

Drop the old profiler?

We currently have two profilers, an instrumenting one and a newer, statistical profiler. Do we need both? The former might be obsolete, but I (felix) am not sure.

--- Probably want to keep the old one, since it doesn't require a signal to work. For example, SDL masks signals IIRC so you couldn't use it to profile an SDL program. See also the conclusion at the end of my blog post for more reasons (sjamaan). Maybe we can investigate if we can reduce the downsides to the current profiler to make it a bit more useful?

--- Statistical profilers have the problem that if a procedure is called a lot but is very fast-running it may be undersampled because the profile interrupt just happens to miss it every time. (jcowan)

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

Moving R7RS support to the core

--- It's Time.™ We already have all the Chicken stuff in libraries, so adding `(scheme *)` libraries should be practically free. This would involve having an `-r7rs` option for both `csi` and `csc`. (jcowan)