Did you consider moving "#lang mzscheme" out as well?<div> </div><div>Robby On Thursday, June 27, 2013, Sam Tobin-Hochstadt wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I've now pushed this set of changes, which pass all the racket tests and build the whole system cleanly. I think the next steps are: - Robby is going to move mzlib/contract. - Matthew is going to modify mzlib/compiler and mzlib/unit200. - Ryan is working on shrinking the db collection. - I posted about shrinking the `pkg` collection and working toward removing parts of the `net` collection. There are also some parts of some collections that aren't needed. Much of `openssl` could go if `pkg` was split. The decompiler and demodularizer could potentially be moved out. Perhaps distributed places could move. Other things to would, in my estimation, be much harder, and would probably be things that are part of `#lang racket`, like the class or unit systems or `match`, or things that are deeply intertwined with `raco setup`, like planet. Sam On Wed, Jun 26, 2013 at 6:38 PM, Robby Findler <<a href="javascript:;" onclick="_e(event, 'cvml', 'robby@eecs.northwestern.edu')">robby@eecs.northwestern.edu</a>> wrote: > I can move mzlib/contract after you get done with other stuff. > > Robby > > > On Wednesday, June 26, 2013, Sam Tobin-Hochstadt wrote: >> >> On Tue, Jun 25, 2013 at 4:32 PM, Sam Tobin-Hochstadt <<a href="javascript:;" onclick="_e(event, 'cvml', 'samth@ccs.neu.edu')">samth@ccs.neu.edu</a>> >> wrote: >> > While moving some files around between packages, I realized that there >> > are a number of things that could be moved out of the core and into >> > packages. Here's a partial list of things that I think are not needed >> > at all by the rest of the core: >> >> I've now done the first step of this work. You can see the results >> here: <a href="https://github.com/plt/racket/pull/373" target="_blank">https://github.com/plt/racket/pull/373</a> >> >> This works to the degree that the core still compiles. No other >> testing has happened yet -- that's the next step. A number of packages >> will need additional dependencies. >> >> I'd like to get feedback on exactly how this is organized. In >> particular, a bunch of things are now in a `compatibility-lib` >> collection: >> >> * almost all of `mzlib` >> * `compatibility/*` >> * `racket/mpair` and `racket/mlist` >> >> There's also the following new packages: `errortrace-lib`, >> `errortrace-doc`, `unstable-contract-lib`, `unstable-options-lib`, >> `sandbox-lib`, `data-lib`, `rackunit`. >> >> The `help` collection moved to `scribble/lib`. >> >> Where there isn't a new documentation package, libraries are mostly >> documented in `unstable` or `racket-doc`. >> >> Things that didn't move: >> >> * `mzlib/compile`: This is used in one place in the compiler, and >> should probably be handled differently. Matthew, any suggestions? >> * `mzlib/unit200`. This is loaded into a new namespace in which code >> is evaluated in `setup/unpack`. I don't understand what is happening >> there, and thus won't change it. It's also still used genuinely in >> `file/gzip`. >> * `mzlib/contract`. This is different enough from `racket/contract` >> that I'd prefer to have someone who knows the contract system better >> handle this. Also, much of the contract system implementation is in >> the `mzlib` directory, which seems odd. >> * `srfi/13`: used in `net/cookie` in a way that's intertwined with >> `srfi/14` and would be hard to remove on its own. >> * `srfi/8`: Used in unmodified srfi code that we probably shouldn't >> change. >> * Other SRFIs -- used in the `db` collection, or depended on by those that >> are. >> >> Sam >> _________________________ >> Racket Developers list: >> <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> </blockquote></div>