Did you consider moving "#lang mzscheme" out as well? Robby
On Thursday, June 27, 2013, Sam Tobin-Hochstadt wrote: > 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 > <ro...@eecs.northwestern.edu <javascript:;>> 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 > >> <sa...@ccs.neu.edu<javascript:;> > > > >> 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: https://github.com/plt/racket/pull/373 > >> > >> 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: > >> http://lists.racket-lang.org/dev >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
