[racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)

At Mon, 30 Jul 2012 15:52:52 -0400, Vincent St-Amour wrote:
> The main advantage (IMO) of having, say, mutable lists in
> `compatibility' is that searching the docs points there instead of to
> `racket'. This makes it clear that they are not a blessed Racket
> feature. This is (IMO) the main point of the `compatibility' collect.

I agree that "compatibility" lets us add features that we don't really
like, but trying to shift existing bad ideas into "compatibility" seems
like a big detour (i.e., I'm agreeing with Matthias).


> Now that we have submodules, are packages still useful?

Submodules do not subsume packages; for example, `package' works in
definition contexts other than top-level modules. Whether packages are
still useful is maybe a moot point, since they don't seem to have been
ever useful. They were developed as an expansion target for an
implementation of ML, but even that implementation didn't use them in
the end.


At Mon, 30 Jul 2012 16:00:12 -0400, Matthias Felleisen wrote:
> I fully and enthusiastically agree with this perspective but I don't think this 
> is high on our list of things to do. 
> 
> When we consider such moves, we should always consider the opportunity cost. 
> What could I accomplish instead? 
> 
> Having said that, I would like to propose that we COPY files/subcollections 
> from racket/ to compatibility/ (and keep them in sync) if we wish to indicate 
> that they are not really rackety. 

That's committed already, so I'm suggesting that we do more work to
un-commit the change. It's the spirit of avoiding more of the
kind of work that you suggest we avoid, though.

If we really want to have two names for these things --- the
compatibility name and the "compatibility" name --- then I think we
should at least consolidate to a single compatibility manual by moving
the documentation for `racket/mpair' and `racket/package' to the
compatibility manual.