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. _________________________ Racket Developers list: http://lists.racket-lang.org/dev