https://github.com/mflatt/not-a-box

https://github.com/mflatt/not-a-box

Last synced: 30 days ago
JSON representation

• Host: GitHub
• URL: https://github.com/mflatt/not-a-box
• Owner: mflatt
• Created: 2017-02-15T15:04:21.000Z (over 7 years ago)
• Default Branch: master
• Last Pushed: 2017-05-05T22:56:13.000Z (over 7 years ago)
• Last Synced: 2024-05-23T04:48:32.304Z (6 months ago)
• Language: Racket
• Size: 2.46 MB
• Stars: 57
• Watchers: 14
• Forks: 5
• Open Issues: 1
• Metadata Files:
  • Readme: README.txt

Awesome Lists containing this project

README

        
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.