-
Notifications
You must be signed in to change notification settings - Fork 5
/
Copy pathREADME.txt
128 lines (90 loc) · 5.01 KB
/
README.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
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.