I don’t think anyone is working on “pkgs/expander”, but just in case: I’m planning to move it to “racket/src/expander”. I’ll add something link a soft link (but not actually a soft link) in “pkgs” so that installing “expander” would use that directory, but “expander” needs to be in “racket/src” so that it’s eventually included in a source distribution.
Meanwhile, I’d like to pick a more specific name than “core” for the layer implemented by “racket/src/cs/core.sls”. “Core” here means the layer that’s implemented before we add on Racket-implemented parts. From talking to Sam, it sounds like this boundary may work for Pycket as well as Racket-on-Chez. But the boundary can be different for different Racket implementations in the long run, and I’d like to avoid the #%kernel mistake. Since the layer is roughly Scheme plus delimited control and proxies (chaperones/impersonators), I’ve considered acronyms like “DCP”, but I’d rather have a proper name. The layer could also be characterized as the one before threads and I/O. Any suggestions?
One question about naming in that case — what’s the name for the layer implemented in C (which includes the thread/regexp/io system, but not the expander)?
That’s currently the abstraction layer implemented in pycket, although we plan to move to the same one as Racket-on-Chez
A convention that gives a name to each of those layers (and more) would be good.
Two (pretty different) possibilities:
- An actual name for the layer — I’d suggest a play on “Racket”, such as “Noise”
- Core, Core+Thread, Core+Expander, etc
I’m starting to like “Noise”
new racket/racket7 <=> mflatt/ChezScheme I force-pushed the latter to better sync with the current cisco/ChezScheme plus 3 pending PRs that racket7 needs