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

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`)?

>> > 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.
>
> 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.

> So, I think option 2 is right for now, and we should eventually spend
> cycles on really getting `mzscheme' out of the core.

Ok, I'll focus on that.

Sam