You are looking at historical revision 42949 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.

The incompatibilities are the following:

• file-read, set-pseudo-random-seed! and random-bytes require a byte-vector argument.
• The "blob" module has been removed and replaced by the R7RS-compatible "chicken.bytevector" module.
• Strings and symbols passed to foreign code are not copied, they are passed directly, any mutations done by external code will be visible on the Scheme side.
• SRFI-4 "blob" conversions have been renamed, a shim egg will be provided that contains all the functionality using the old names, but needs to be imported in a separate step.
• String-locatives index by character position, not byte-position. Size changes due to destructive string-mutation are not detected or handled.
• "blob" read-syntax ("#${...}") has been removed.
• read-u8vector, read-u8vector! and write-u8vector have been removed, use the bytevector I/O operations from (chicken io) instead.
• Removed set-port-name!, use SRFI-17 setter instead.
• make-input-port and make-output-port take additional port methods as keyword arguments.

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)