not-a-box

not-a-box copied to clipboard

Moved to

https://github.com/racket/racket7

Work-in-progress for running Racket on Chez Scheme.

[Requires the current development version of Chez Scheme from https://github.com/cisco/ChezScheme]

The files:

.sls - Chez Scheme libraries that provide implementations of Racket primitives, building up to the Racket expander. The "core.sls" library is implemented directly in Chez. For most other cases, a corresponding "linklet/.scm" file contains the implementation extracted from from expanded and flattened Racket code.

core/*.ss - Part of "core.sls" (via include) to implement core data structures (especially immutable hash tables), structs, etc.

*.scm - a temporary compatibility layer to be included into an ".sls" library.

linklet/*.scm - A conversion from a ".rktl" file to be includedd into an ".sls" library.

linklet/*.rktl - A Racket library (e.g., to implement regexps) that has been fully macro expanded and flattened into a linklet. A linklet's only free variables are "primitives" that will be implemented by various ".sls" libraries in layers. See "Builing linklets from source" below for more information.

primitive/*.scm - for "expander.sls", tables of bindings for primitive linklet instances.

convert.rkt - A linklet-to-library-body compiler, which is used to convert a ".rktl" file to a ".scm" file to inclusion in an ".sls" library.

demo/.ss - Chez scripts to check that a library basically works. For example "demo/regexp.ss" runs the regexp matcher on a few examples. To run "demo/.ss", use make *-demo.

schemify/schemify.rkt - Source to "schemify.scm", which is part of the implementation of linklets --- specifically, for compiling a Racket linklet to a Chez procedure.

other *.rkt - Racket scripts like "convert.rkt" or comparisions like "demo/regexp.rkt". For example, you can run "demo/regexp.rkt" and compare the reported timing to "demo/regexp.ss".

Building linklets from source:

Most ".rktl" sources are the the "linklet" branch of the Racket repo that's currently at

        https://github.com/mflatt/racket

For example, "linklet/regexp.rktl" is generated from make regexp-src in the "pkgs/regexp". The "linklet/schemify.rktl" linklet is generated from "schemify/schemify.rkt" here, though.

To rebuild those sources, set the LINKLET_RACKET environment variable to a built git clone of the "linklet" branch (it's probably enough to make with PKGS="compiler-lib"), and then use make all-linklets.

Running "demo/expander.ss":

A make expander-demo builds and tries the expander on simple examples. If LINKLET_RACKET is set as for building linklets, the "expander-demo.ss" also tries loading racket/base from source.

Dumping linklets and schemified linklets:

Set the PLT_LINKLET_SHOW environment variable to pretty print each linklet generated by the expander and its schemified form that is passed on the Chez.

Status and thoughts on various Racket subsystems:

• "core-struct.ss" is half an implementation of Racket structures, with structure-type properties, applicable structs, gen:equal+hash, and so on in terms of Chez records. Applicable structs work by adding an indirection to each function call (in a little compiler from fully-expanded code to Chez) when the target is not obviously a plain procedure; with the analysis in "schemify/schemify.rkt", the indirection is not needed often in a typical program, and the overhead appears to be light when it is needed. The rest of the implementation of Racket structures looks straightforward.

• Racket's delimited continuations, continuation marks, threads, and events are mostly in place (see "core-control.ss", "core-engine.ss", and the source for "thread.rktl"), but to integrate I/O, the scheduler needs access to the OS's select()/epoll()/kqueue()/WaitMultipleEvents().

• The Racket FFI looks a lot like the Chez FFI, so I expect that to mostly work, although there may be allocation issues.

• The Racket and Chez numeric systems likely differ in some ways, and I don't know how much work that will be.

• For futures, Chez exposes OS-level threads with limited safety guarantees. An implementation of futures can probably take advantage of threads with thread-unsafe primitives wrapped to divert to a barrier when called in a future.

• Ephemerons require support from Chez. (Pull request submitted.)

• GC-based memory accounting similarly seems to require new support, but that can wait a while.

• Extflonums will probably exist only on the Racket VM for a long while.

• Bytecode, as it currently exists, goes away. Platform-independent ".zo" files might contain fully expanded source (possibly also run through Chez's source-to-source optimizer), and maybe raco setup will gain a new step in creating platform-specific compiled code.