I was thinking of libraries, accessed via require. If we just had (require racket/aliases), then that would be tantamount to doing #lang racket (probably), given all of the dependencies that it would pull in. If we instead had (require racket/set/aliases), then I could use non-ASCII stuff without the big footprint.
Robby On Tue, Jul 26, 2011 at 2:06 PM, Neil Van Dyke <n...@neilvandyke.org> wrote: > Robby Findler wrote at 07/26/2011 02:02 PM: >> >> It would be nice to be able to use some of those aliases without >> having to pull in huge piles of stuff, tho. Is there a way to make >> that happen? racket/aliases/<x> where <x> is the same as racket/<x>, >> but with aliases added in? (Or maybe we just add all the aliases to >> racket/<x> directly? Or maybe racket/<x>/aliases?) >> > > If you're speaking of adding new "#lang" names for this extension, I think > that's a slippery slope that doesn't scale to the combinations of multiple > incremental language extensions of equal importance that we'll wish to add. > > I think that extensions like this are what "require" and the monolithic > "#lang racket" are for. > > For this extension, I'd favor a "racket/cute" (or whatever people want to > call it) module that is included in "#lang racket" language but not in > "#lang racket/base". > > Or even put the extension in "#lang racket/base", if that's deemed the only > alternative to creating additional "#lang" combination names. Anything but > more "#lang" combination names. > > (I think it's already a bit awkward how Typed Racket uses "#lang" > combination names, but TR's use is understandable right now, and TR is of > special importance.) > > -- > http://www.neilvandyke.org/ > _________________________________________________ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/users > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users