At Thu, 27 Jun 2013 09:04:46 -0400, Sam Tobin-Hochstadt wrote: > On Thu, Jun 27, 2013 at 9:02 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > > This all looks right to me. > > Any thoughts on `mzlib/unit200` or `mzlib/compile`?
I imagine fixing them later by * moving the useful part of `mzlib/compile' and putting a compatibility `mzlib/compile' into "compatbility-lib"; * revising `file/gzip' to not use `mzlib/unit200'; and * dropping support for arbitrary unpack code in ".plt" files (and instead just pattern match on the only `unit' expression form that is ever used in practice). > Sam > > > At Wed, 26 Jun 2013 17:38:49 -0500, Robby Findler 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 _________________________ Racket Developers list: http://lists.racket-lang.org/dev
