[racket-dev] Things we could move out of the core

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Thu Jun 27 09:11:15 EDT 2013

At Thu, 27 Jun 2013 09:04:46 -0400, Sam Tobin-Hochstadt wrote:
> On Thu, Jun 27, 2013 at 9:02 AM, Matthew Flatt <mflatt at 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
> >> <samth at 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

Posted on the dev mailing list.