Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
Yesterday, Vincent St-Amour wrote: At Tue, 31 Jul 2012 07:42:53 -0600, Matthew Flatt wrote: 1. Revert the addition of `compatibility/package' and `compatibility/mpair', including the documentation changes (but maybe add back some text to discourage misuse of these libraries). 2. Leave things as they are, but move the sections that document `racket/package' and `racket/mpair' out of the Reference and into the same Compatibility document that describes `compatibility/package' and `compatibility/mpair'. I'll go with the second one. I think it makes it clearer that these features are not Rackety. -1 for leaving `package' there -- as questionable as its utility might be, I don't think that there was ever any use of it that fell under a compatibility category. (OTOH, I have at least one use of it that is definitely not compatibility.) -- ((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
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
I think the idea is that compatibility means we are keeping this to be backwards compatible with unknown code that is using it (or at least, that's one of the meanings). Robby On Wed, Aug 1, 2012 at 6:44 PM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Vincent St-Amour wrote: At Tue, 31 Jul 2012 07:42:53 -0600, Matthew Flatt wrote: 1. Revert the addition of `compatibility/package' and `compatibility/mpair', including the documentation changes (but maybe add back some text to discourage misuse of these libraries). 2. Leave things as they are, but move the sections that document `racket/package' and `racket/mpair' out of the Reference and into the same Compatibility document that describes `compatibility/package' and `compatibility/mpair'. I'll go with the second one. I think it makes it clearer that these features are not Rackety. -1 for leaving `package' there -- as questionable as its utility might be, I don't think that there was ever any use of it that fell under a compatibility category. (OTOH, I have at least one use of it that is definitely not compatibility.) -- ((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 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
20 minutes ago, Robby Findler wrote: I think the idea is that compatibility means we are keeping this to be backwards compatible with unknown code that is using it (or at least, that's one of the meanings). Sounds like `scheme/nest' should be there too then. But in any case, what bugs me about putting `*/package' there is that there's no substitute for it, so labeling it as such seems wrong. -- ((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
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
I meant literal file copies (or links if that works everywhere). And I think that would satisfy Matthew too. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
At Mon, 30 Jul 2012 19:45:07 -0400, Vincent St-Amour wrote: At Mon, 30 Jul 2012 14:52:06 -0600, Matthew Flatt wrote: 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. To make sure I understand correctly, you're suggesting that: - We keep the `compatibility' collect. - We keep `compatibility/defmacro'. - We remove `compatibility/mpair' and `compatibility/package', and move them back to `racket/mpair' and `racket/package', respectively. - We leave the reference and the compatibility manual as is, with docs for `racket/mpair' and `racket/package' in the compatibility manual. If that's what you're suggesting, I'll implement it. I'm sorry that I've been so unclear! To start afresh, here are two suggestions, which are mutually exclusive. The first is my preference: 1. Revert the addition of `compatibility/package' and `compatibility/mpair', including the documentation changes (but maybe add back some text to discourage misuse of these libraries). 2. Leave things as they are, but move the sections that document `racket/package' and `racket/mpair' out of the Reference and into the same Compatibility document that describes `compatibility/package' and `compatibility/mpair'. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
On Tue, Jul 31, 2012 at 6:42 AM, Matthew Flatt mfl...@cs.utah.edu wrote: To start afresh, here are two suggestions, which are mutually exclusive. The first is my preference: 1. Revert the addition of `compatibility/package' and `compatibility/mpair', including the documentation changes (but maybe add back some text to discourage misuse of these libraries). I definitely think we should keep `mpair` as a more-than-compatibility library. It's useful in real data structures, and it's nice not to have to roll your own mutable linked list when it's the right choice. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
At Tue, 31 Jul 2012 09:26:56 -0700, Sam Tobin-Hochstadt wrote: On Tue, Jul 31, 2012 at 6:42 AM, Matthew Flatt mfl...@cs.utah.edu wrote: To start afresh, here are two suggestions, which are mutually exclusive. The first is my preference: 1. Revert the addition of `compatibility/package' and `compatibility/mpair', including the documentation changes (but maybe add back some text to discourage misuse of these libraries). I definitely think we should keep `mpair` as a more-than-compatibility library. It's useful in real data structures, and it's nice not to have to roll your own mutable linked list when it's the right choice. Mutable pair functions are in `racket/base', I didn't touch these and am not planning to. Mutable list functions, though, I moved. The name is misleading. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
At Tue, 31 Jul 2012 14:08:16 -0400, Vincent St-Amour wrote: Mutable pair functions are in `racket/base', I didn't touch these and am not planning to. Mutable list functions, though, I moved. The name is misleading. Should `compatibility/mpair' be `compatibility/mlist' (while `racket/mpair' keeps the misleading name)? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
At Tue, 31 Jul 2012 13:04:40 -0600, Matthew Flatt wrote: At Tue, 31 Jul 2012 14:08:16 -0400, Vincent St-Amour wrote: Mutable pair functions are in `racket/base', I didn't touch these and am not planning to. Mutable list functions, though, I moved. The name is misleading. Should `compatibility/mpair' be `compatibility/mlist' (while `racket/mpair' keeps the misleading name)? Good idea. I'll do that. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
At Fri, 20 Jul 2012 16:33:54 -0400, Vincent St-Amour wrote: 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. Sorry that I'm so late to this thread. I think a compatibility collection is a good idea, and it's a fine place for `defmacro'. I don't think `racket/...' libraries should move there, though. When the next big language shift comes, we should leave out some libraries that are now in racket, and then it may make sense to add some left-out ones to compatibility. As long as they stick around in racket though (for compatibility!), I think there's little advantage in adding them to compatibility. FWIW, the `package' form wasn't even intended for compatibility. It was intended to support namespace management --- possibly as an expansion target for macros --- and to work in contexts other than module top levels. It hasn't turned out to be useful, though. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
At Mon, 30 Jul 2012 13:10:28 -0600, Matthew Flatt wrote: At Fri, 20 Jul 2012 16:33:54 -0400, Vincent St-Amour wrote: 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. Sorry that I'm so late to this thread. I think a compatibility collection is a good idea, and it's a fine place for `defmacro'. I don't think `racket/...' libraries should move there, though. When the next big language shift comes, we should leave out some libraries that are now in racket, and then it may make sense to add some left-out ones to compatibility. As long as they stick around in racket though (for compatibility!), I think there's little advantage in adding them to compatibility. 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. FWIW, the `package' form wasn't even intended for compatibility. It was intended to support namespace management --- possibly as an expansion target for macros --- and to work in contexts other than module top levels. It hasn't turned out to be useful, though. Now that we have submodules, are packages still useful? If not, we should encourage the use of submodules over packages, and putting packages in `compatibility' makes it clear that they are not the preferred option. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
On Jul 30, 2012, at 3:52 PM, 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 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. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [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. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
At Mon, 30 Jul 2012 16:00:12 -0400, Matthias Felleisen wrote: 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. Assuming you mean keeping the same interface re-providing bindings from one to the other, as opposed to duplicating the implementation, then that's what I did. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)
At Mon, 30 Jul 2012 14:52:06 -0600, Matthew Flatt wrote: 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. To make sure I understand correctly, you're suggesting that: - We keep the `compatibility' collect. - We keep `compatibility/defmacro'. - We remove `compatibility/mpair' and `compatibility/package', and move them back to `racket/mpair' and `racket/package', respectively. - We leave the reference and the compatibility manual as is, with docs for `racket/mpair' and `racket/package' in the compatibility manual. If that's what you're suggesting, I'll implement it. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
