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. _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
