On Fri, Jun 28, 2013 at 5:17 PM, Matthew Flatt <mfl...@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 <mfl...@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 >> >> <ro...@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. > Meanwhile, I worry that options 1 and 3 can create subtle and confusing > bugs/incompatibilities. (I've spent a lot of time on problems that > happened due to accidentally choosing similar options in the past.) (1) definitely has the potential for subtle bugs. I believe that (3) is semantics preserving *except* insofar as some part of the core was using the `mzscheme` namespace creation functions, and would thus work differently. However, there are only two places in the core that use `make-namespace` from `mzscheme`. They are (a) the `setup/unpack` code using `eval` that you plan to remove and (b) a part of `compiler/private/xform.rkt` for loading precompiled headers. I don't know what the latter does, or if changing it to use a Racket namespace would have the potential to introduce bugs. But yes, there's definitely a worry about subtle bugs here. Sam _________________________ Racket Developers list: http://lists.racket-lang.org/dev
