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 `include`d into an
         ".sls" library.

 linklet/*.scm - A conversion from a ".rktl" file to be `included`d
         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.