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

At Fri, 28 Jun 2013 23:25:22 -0400, Sam Tobin-Hochstadt wrote:
> On Fri, Jun 28, 2013 at 6:02 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> > At Fri, 28 Jun 2013 17:43:42 -0400, Sam Tobin-Hochstadt wrote:
> >> On Fri, Jun 28, 2013 at 5:17 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> >> > At Fri, 28 Jun 2013 17:08:19 -0400, Sam Tobin-Hochstadt wrote:
> >> >> On Fri, Jun 28, 2013 at 5:02 PM, Matthew Flatt <mflatt at cs.utah.edu> 
> wrote:
> >> >> > At Fri, 28 Jun 2013 14:38:03 -0400, Sam Tobin-Hochstadt wrote:
> >> >> >> 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?
> >> >> >>
> >> >> >> I've now created another pull request that does this, here:
> >> >> >> https://github.com/plt/racket/pull/377
> >> >> >>
> >> >> >> There's one remaining question.  The `make-base-namespace` procedure
> >> >> >> provided by `mzscheme` attaches the `mzscheme` module.  But this pull
> >> >> >> request removes that module, so it can't be attached or required in
> >> >> >> this code.  The alternatives are:
> >> >> >>
> >> >> >> 1. Just attach/require `scheme/mzscheme`.  Slightly incompatible in
> >> >> >> some corner cases.
> >> >> >> 2. Don't remove `mzscheme` from the core.
> >> >> >> 3. Remove `make*-namespace` from `scheme/mzscheme` and implement them
> >> >> >> in the `mzscheme` collection in the `mzscheme` package.
> >> >> >>
> >> >> >> I'm currently leaning toward 3 but I'd appreciate anyone else's 
> thoughts.
> >> >> >
> >> >> > Is there some reason that `scheme/mzscheme' can't move to the
> >> >> > "mzscheme" package (along with `racket/private/stxmz-body')?
> >> >>
> >> >> Because large portions of the core are written in the `mzscheme`
> >> >> language (or `scheme/mzscheme`, after my patch), some of which feature
> >> >> evaluating code in mzscheme-like namespaces.  If we can somehow get
> >> >> around the latter problem, then the former is a Small Matter of
> >> >> Programming, but it'll take a little while.
> >> >
> >> > Ah --- I had not actually looked at 9587a2f.
> >> >
> >> > I guess I'm confused on the goal, since I don't see changing `mzscheme'
> >> > to `scheme/mzscheme' as a step forward. Can you say more about the
> >> > intent of changing `mzscheme' to `scheme/mzscheme'?
> >>
> >> The intent is to reduce the API surface area provided by the core.
> >> Note that `scheme/mzscheme` is not a documented API.  Thus, moving the
> >> `mzscheme` language and collection would require anyone who depended
> >> on them to explicitly depend on another package. At some later point,
> >> we finish implementing the core without using `scheme/mzscheme`, move
> >> the actual implementation of `mzscheme` to the `mzscheme` package,
> >> without any compatibility problems.
> >
> > I see what you mean, but it feels wrong to me that `scheme/mzscheme'
> > exists and isn't documented. I'd prefer to work toward getting it in
> > the right package and documented.
> 
> Do you see an advantage to documenting it, over just having `mzscheme`
> documented (and perhaps moving `scheme/mzscheme` to `racket/private`)?

No, I agree with your suggestion (I think) that just having `mzscheme'
would be better.


> > There's also the issue that `scheme/mzscheme' introduces an
> > `for-syntax' import of `scheme/mzscheme', and not a `for-syntax' import
> > of `mzscheme', so `make-base-namespace' would disappear from phase 1 in
> > `mzscheme' --- if I'm following correctly.
> 
> I don't follow this. As far as I can tell, neither `mzscheme` nor
> `scheme/mzscheme` introduce `for-syntax` imports of anything.

The `#%module-begin' of `mzscheme' introduces `(#%require (for-syntax
scheme/mzscheme))' into the module body --- a leftover from the days
before phase-1 exports were supported.

Changing the introduced `require' from `scheme/mzscheme' to `mzscheme'
should be ok, as far as I can tell. We just don't want to accidentally
change the bindings that are imported by that `require'.