Three hours ago, Vincent St-Amour wrote: > > I'm not sure this belongs in `racket'. This is not a Racket feature. > It's closer to a CL compatibility library.
+1 > How about having a `compatibility' collect, which would include this > and things like `racket/package' (compatibility with Chez) and > `racket/mpair' (compatibility with Scheme)? It would be harder to > confuse these things with blessed Racket features. +1 Two hours ago, Ryan Culpepper wrote: > > -1 > > I think proliferating indirections and aliases is just as bad as (or > maybe worse than) proliferating top-level collections. If it's in > mzlib/ and it's still really useful, move it to racket/ (or data/, > etc). If it isn't (eg, mzlib/defmacro, perhaps mzlib/thread), then > just leave it alone. +1 for the sentiment of having too many redirections both at the file level and at the binding level (like the many @scheme bindings in scribble). But OTOH, I did mention that one of the weird things when I talk about `defmacro' in class is the arbitrary looking "mzlib"... So I think that organized expirations address this nicely. Perhaps it's another argument in favor of throwing a syntax error at the end-of-life of a deprecated library/name, one that explicitly says "use `compat/defmacro' instead of `mzlib/defmacro'", and leaving that on for a release or two. This will save people a dig through the docs/mailing-list/google to find out how to change things. (BTW, I think that the `scheme' collection could go this way too.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _________________________ Racket Developers list: http://lists.racket-lang.org/dev