[plt-dev] some Racket proposals & implementation

At Sat, 3 Apr 2010 20:26:05 -0600, Jay McCarthy wrote:
> The main issue seems to be that sstruct uses "many libraries at
> compile time". In particular that's scheme/match, dict, and
> syntax/parse. If we can't use our high level language and awesome
> macro tools in our main language, what's the point?

To use it for the 99.9...% of modules that aren't implementing the core
libraries.

Another way to look at this particular example: If the `define-struct'
of `racket/base' is implemented in terms of `racket/match',
`racket/dict', and `syntax/parse', then those libraries cannot be
implemented using the `racket/base' language.

> In this particular case, my batch compiler with its straight-forward
> dead-code elimination allows you to use "scheme" and get the smallest
> bit that you actually need. It gets smaller startup time and memory
> footprint. Currently it's not perfect, but it seems like it is the
> right direction when you're concerned with memory footprint, rather
> than holding back what we otherwise believe are good features.

I'm a fan of the whole-program batch compiler, but it assumes that
`eval' and `expand' won't be used. It doesn't apply to someone using
`mzc --c-mods racket/base' for an embedding executable. It doesn't
apply to a language `X' that uses `racket/lang' at compile time and
where language `X' is used to compile another 500 modules (where
startup time for `X' turns into phase-1 initialization time for each of
the 500 modules).

> As a corollary, I see this define-sstruct as a nascent lambda/kw. If
> we really value it, then it should be the default and we should do
> what it takes to make it work.

Agreed, and maybe we find a better answer in the long run --- maybe
something that lets us combine the benefits of bootstrapping and
language towers.

For Racket 5.0, though, making it work means implementing
`define-sstruct' in a more primitive language.