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

Yes, since `scheme/mzscheme` is the same language for the (many) parts
of the core that need it.  There are a number of other small bits that
I'll do as well.

On Thu, Jun 27, 2013 at 8:45 PM, Robby Findler
<robby at eecs.northwestern.edu> wrote:
> 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
>> <robby at eecs.northwestern.edu> 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>
>> >> 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