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

At Thu, 27 Jun 2013 09:17:16 -0400, Sam Tobin-Hochstadt wrote:
> On Thu, Jun 27, 2013 at 9:11 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> > 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).
> 
> Do you plan to do this before the next release?

Yes, right away.

> This brings up a larger question -- what kind of
> backwards-compatibility commitment do we plan to make for the contents
> of the "core", vs packages that need to be installed? I can imagine a
> few possibilities: (1) anything shipped with the core is still shipped
> with the core in later releases, (2) code in the core may migrate to
> packages that clients will need to add as dependencies, or possibly
> other solutions.

I'd like a solution where the content of the core is not guaranteed,
and a package always needs to declare what it depends on. That is, the
core is analogous to an unspecified top level environment, and each
package should declare at least an initial dependency analogous to a
module always starting with `#lang'.

So, some package "base" could be the core that we have today, and then
if we shrink the core, then the "base" package can change to load in
at least all the old things, while newer packages can depend on a new
and smaller "base2", etc.