Re: [racket-dev] else clauses: possible change to match?
On Mon, May 6, 2013 at 7:29 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Mon, 6 May 2013 07:02:47 -0600, Jay McCarthy wrote: On Mon, May 6, 2013 at 6:52 AM, Matthew Flatt mfl...@cs.utah.edu wrote: 3. And a side-comment: I hope that there will be something better than actual `racket2' used in code... Suggestions are welcome. Maybe rename the current one to `racket1' and possibly have code in packages use that unless it's declared new somehow? Surely the meaning of `#lang racket' shouldn't depend on its context --- otherwise we're moving back toward the world where no fragment of code has a useful meaning unless you know its full context. The meaning of #lang racket currently depends on its context because we make incompatible changes of any kind. (Even adding a single binding is incompatible with some uses like (require racket my/library).) Granted. Still, there are many programs that start `#lang racket' that are well-defined because they don't depend on the differences across versions. As a practical matter, we try to limit differences in `racket' to make that happen as much as possible, and I think we should continue to move even more in the direction of making modules less dependent on implicit version context. For the scale of changes that we want to make for `racket2', the number of programs that would be the same with `#lang racket' and `#lang racket2' will be drastically smaller than the number of `#lang racket' programs that work across versions --- so much that I don't currently believe it's practical to call both languages `racket'. FWIW, I don't find #lang racket2 ugly. I think that it is fine for #lang racket to continue to change in this way. The problem I see us as needing to solve is how to help people deal with incompatible changes. One idea is to create a system whereby (require v5.2.1/racket/list) is the interface to racket/list from 5.2.1 and #lang v5.2.1/racket is the racket from that version. Most of these versions would just be about hiding some bindings, but it lays the framework for more exhaustive changes. I think it would be easy to maintain these, because most deltas are small. But as they become more complex and less used, we can spin them out to packages to keep the main repo clean. That sounds like a good approach for dealing with the finer differences among versions and for writing code that last forever. I think we'll have a hard time getting programmers to write versions in all useful code, though. If that's the case, we're left having to make some compromise on module/language changes versus compatibility for useful code. I agree that most people probably wouldn't do it, but I think having the infrastructure in place would be very valuable, because when you find that you code is broken, you can look up what version of Racket was released at the time and get it working right away, then look through the compatibility modules to port your code. Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
On Monday, May 6, 2013, Jay McCarthy wrote: On Mon, May 6, 2013 at 7:29 AM, Matthew Flatt mfl...@cs.utah.edujavascript:; wrote: At Mon, 6 May 2013 07:02:47 -0600, Jay McCarthy wrote: On Mon, May 6, 2013 at 6:52 AM, Matthew Flatt mfl...@cs.utah.edujavascript:; wrote: 3. And a side-comment: I hope that there will be something better than actual `racket2' used in code... Suggestions are welcome. Maybe rename the current one to `racket1' and possibly have code in packages use that unless it's declared new somehow? Surely the meaning of `#lang racket' shouldn't depend on its context --- otherwise we're moving back toward the world where no fragment of code has a useful meaning unless you know its full context. The meaning of #lang racket currently depends on its context because we make incompatible changes of any kind. (Even adding a single binding is incompatible with some uses like (require racket my/library).) Granted. Still, there are many programs that start `#lang racket' that are well-defined because they don't depend on the differences across versions. As a practical matter, we try to limit differences in `racket' to make that happen as much as possible, and I think we should continue to move even more in the direction of making modules less dependent on implicit version context. For the scale of changes that we want to make for `racket2', the number of programs that would be the same with `#lang racket' and `#lang racket2' will be drastically smaller than the number of `#lang racket' programs that work across versions --- so much that I don't currently believe it's practical to call both languages `racket'. FWIW, I don't find #lang racket2 ugly. I think that it is fine for #lang racket to continue to change in this way. The problem I see us as needing to solve is how to help people deal with incompatible changes. One idea is to create a system whereby (require v5.2.1/racket/list) is the interface to racket/list from 5.2.1 and #lang v5.2.1/racket is the racket from that version. Most of these versions would just be about hiding some bindings, but it lays the framework for more exhaustive changes. I think it would be easy to maintain these, because most deltas are small. But as they become more complex and less used, we can spin them out to packages to keep the main repo clean. That sounds like a good approach for dealing with the finer differences among versions and for writing code that last forever. I think we'll have a hard time getting programmers to write versions in all useful code, though. If that's the case, we're left having to make some compromise on module/language changes versus compatibility for useful code. I agree that most people probably wouldn't do it, but I think having the infrastructure in place would be very valuable, because when you find that you code is broken, you can look up what version of Racket was released at the time and get it working right away, then look through the compatibility modules to port your code. We currently have a path for this: download the old version. Do you think we can do substantially better than that with a reasonable amount of effort? FWIW, I think that there are two significant advantages to using a 5.3.1 compatibility module in 5.3.4 (or whatever): - bug fixes (esp in the compiler and runtime system) - eases porting (as you can move files piecemeal) My worry is on the effort side. Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
More generally, the role of `else' in `cond' is to select a particular production in the grammar of `cond' clauses, and keywords are normally the right way to do that in Racket. Keywords are normally right because they are syntactically distinct from expressions --- and so using a keyword avoids various potential ambiguities and sources of confusion. At Sat, 4 May 2013 10:36:14 -0500, Robby Findler wrote: I think the bad property is the shadowing of the else identifier and Matthew's point is that one way to avoid that is to not use an identifier at all. The racket2 wiki currently says try this out so I guess it isn't something people believe will definitely be better, but something to explore. Robby On Sat, May 4, 2013 at 10:33 AM, Laurent laurent.ors...@gmail.com wrote: (that was assuming Ryan's assertion that [...]Matthew say that he would have used a keyword for `else` in `cond` if he had it to do over again, which seem to mean that even in Racket2 Matthew would prefer `#:else' over `[else ...]' ?) On Sat, May 4, 2013 at 5:14 PM, Laurent laurent.ors...@gmail.com wrote: Matthew, Out of curiosity, could you explain why you'd prefer #:else everywhere instead of [else ...] ? Would such an #:else allow for multi-line bodies? On Sat, May 4, 2013 at 5:06 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Sat, 4 May 2013 09:15:22 -0500, Robby Findler wrote: On Sat, May 4, 2013 at 9:07 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 3 May 2013 17:29:52 -0400, Eli Barzilay wrote: A few minutes ago, Robby Findler wrote: FWIW, this was the bug in redex that prompted me to send this message (it was there for some time since it wasn't a syntax error it was similar in spirit to the code I posted; things broke when #f was an argument) [I think that it's good to have a much more relaxed policy about breaking compatibility in cases like this: so far there was no real code found that uses the feature, but there is one instance of code that would get fixed by the change...] Well, Ian provided an example from real code, right? Ian is willing to change his code, but the code sounds real. There's also the use in `unparse-pattern' in Redex. Maybe that's the troublesome one that Robby has in mind changing (or he would be happy to change it, obviously), but it's another real example. No, that was not the example. The code I sent at the beginning of the thread was an adjusted version of the bug that hid in Redex for, roughly, months. It was a real bug and caused real problems and we knew something was wrong but didn't find it for some time. In other words, this isn't some made-up, code cleanliness-based request. Yes, I understand that you faced a real bug. I hedged above on `unparse-pattern' not to suggest that your actual bug was uninteresting, but to suggest that I might misunderstand the relationship between the bug and the current state of our repository. All else being equal, I'm definitely in favor of a change to a sensible `else' for `match'. The else that isn't equal, however, is backward compatibility, and I think we're at the right point in our development cycle to defer backward incompatibilities to the next language --- hence my vote to defer. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
As a generalization, maybe Racket2 could keep the invariant `#:else' is
the absorbing (default) case of any multi-arm form ?
On Sun, May 5, 2013 at 4:30 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
More generally, the role of `else' in `cond' is to select a particular
production in the grammar of `cond' clauses, and keywords are normally
the right way to do that in Racket. Keywords are normally right because
they are syntactically distinct from expressions --- and so using a
keyword avoids various potential ambiguities and sources of confusion.
At Sat, 4 May 2013 10:36:14 -0500, Robby Findler wrote:
I think the bad property is the shadowing of the else identifier and
Matthew's point is that one way to avoid that is to not use an identifier
at all.
The racket2 wiki currently says try this out so I guess it isn't
something people believe will definitely be better, but something to
explore.
Robby
On Sat, May 4, 2013 at 10:33 AM, Laurent laurent.ors...@gmail.com
wrote:
(that was assuming Ryan's assertion that [...]Matthew say that he
would
have used a keyword for `else` in `cond` if he had it to do over
again,
which seem to mean that even in Racket2 Matthew would prefer `#:else'
over
`[else ...]' ?)
On Sat, May 4, 2013 at 5:14 PM, Laurent laurent.ors...@gmail.com
wrote:
Matthew,
Out of curiosity, could you explain why you'd prefer #:else everywhere
instead of [else ...] ?
Would such an #:else allow for multi-line bodies?
On Sat, May 4, 2013 at 5:06 PM, Matthew Flatt mfl...@cs.utah.edu
wrote:
At Sat, 4 May 2013 09:15:22 -0500, Robby Findler wrote:
On Sat, May 4, 2013 at 9:07 AM, Matthew Flatt mfl...@cs.utah.edu
wrote:
At Fri, 3 May 2013 17:29:52 -0400, Eli Barzilay wrote:
A few minutes ago, Robby Findler wrote:
FWIW, this was the bug in redex that prompted me to send this
message (it was there for some time since it wasn't a syntax
error
it was similar in spirit to the code I posted; things
broke
when #f was an argument)
[I think that it's good to have a much more relaxed policy
about
breaking compatibility in cases like this: so far there was no
real
code found that uses the feature, but there is one instance of
code
that would get fixed by the change...]
Well, Ian provided an example from real code, right? Ian is
willing
to
change his code, but the code sounds real.
There's also the use in `unparse-pattern' in Redex. Maybe that's
the
troublesome one that Robby has in mind changing (or he would be
happy
to change it, obviously), but it's another real example.
No, that was not the example. The code I sent at the beginning of
the
thread was an adjusted version of the bug that hid in Redex for,
roughly,
months. It was a real bug and caused real problems and we knew
something
was wrong but didn't find it for some time.
In other words, this isn't some made-up, code cleanliness-based
request.
Yes, I understand that you faced a real bug. I hedged above on
`unparse-pattern' not to suggest that your actual bug was
uninteresting, but to suggest that I might misunderstand the
relationship between the bug and the current state of our repository.
All else being equal, I'm definitely in favor of a change to a
sensible
`else' for `match'. The else that isn't equal, however, is backward
compatibility, and I think we're at the right point in our
development
cycle to defer backward incompatibilities to the next language ---
hence my vote to defer.
_
Racket Developers list:
http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
Keywords are normally right because they are syntactically distinct from expressions --- and so using a keyword avoids various potential ambiguities and sources of confusion. Isn't this only true for default bindings of #%datum? It seems like macros which assume this lose compatibility with #langs that allow keywords as expressions. I'm not sure whether we want to support that or not, but it seems wrong to say that they are syntatically distinct from expressions. On Sun, May 5, 2013 at 9:03 AM, Eli Barzilay e...@barzilay.org wrote: [shuffled] Yesterday, Matthew Flatt wrote: Meanwhile, it might be worth adding support for `#:else' to `cond', `case', and `match'. That would be backward compatible, and we could see whether we like it enough to do things that way in `racket2'. 1. Doesn't that make an argument against using traditional keywords? Perhaps it's a point for having more symbolic comparisons for keywords? (I'm not objecting to keywords -- just trying to figure out the implications of such a move.) IOW, if all such things switched to #:keywords, what would be a good use case for identifiers? 2. Can we also think of a better keyword syntax in racket2 if it's going to be used more? IIRC, the main arguments against `foo:' or `:foo' were existing code, but existing code will need to be modified... 3. And a side-comment: I hope that there will be something better than actual `racket2' used in code... Maybe rename the current one to `racket1' and possibly have code in packages use that unless it's declared new somehow? (The following is all filed under a non-important comment.) Well, Ian provided an example from real code, right? Ian is willing to change his code, but the code sounds real. There's also the use in `unparse-pattern' in Redex. Maybe that's the troublesome one that Robby has in mind changing (or he would be happy to change it, obviously), but it's another real example. IIUC, Ian said that he doesn't actually use that code, and the redex use is exactly what would get unbroken (I think, I didn't look at the code). I'm just saying that there are cases where it's worth breaking strict compatibility if it fixes more code than it breaks -- having (+ 1 2) = 4 is an exaggerated case of this, and relying on `else' being bound seems like it's closer to that end. Especially given that (match x ... [else ... else ...]) would usually be a quick unbound identifier error. (And BTW, I think that `match' is also an exceptional example in how this will go: (let ([else 1]) (match x [else ...])) which is a little more confusing than the same with `cond'.) -- ((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] else clauses: possible change to match?
On 05/05/2013 12:49 PM, Eric Dobson wrote: Keywords are normally right because they are syntactically distinct from expressions --- and so using a keyword avoids various potential ambiguities and sources of confusion. Isn't this only true for default bindings of #%datum? It seems like macros which assume this lose compatibility with #langs that allow keywords as expressions. I'm not sure whether we want to support that or not, but it seems wrong to say that they are syntatically distinct from expressions. I think it goes the other way around: we want keywords not be be expressions, so we would discourage languages from defining #%datum macros that accept them. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
At Fri, 3 May 2013 17:29:52 -0400, Eli Barzilay wrote: A few minutes ago, Robby Findler wrote: FWIW, this was the bug in redex that prompted me to send this message (it was there for some time since it wasn't a syntax error it was similar in spirit to the code I posted; things broke when #f was an argument) [I think that it's good to have a much more relaxed policy about breaking compatibility in cases like this: so far there was no real code found that uses the feature, but there is one instance of code that would get fixed by the change...] Well, Ian provided an example from real code, right? Ian is willing to change his code, but the code sounds real. There's also the use in `unparse-pattern' in Redex. Maybe that's the troublesome one that Robby has in mind changing (or he would be happy to change it, obviously), but it's another real example. Given these examples from the code we know, I reluctantly vote against the change, due to concerns with backward compatibility --- and, yes, from the sense that these issues are better addressed via `racket2'. Meanwhile, it might be worth adding support for `#:else' to `cond', `case', and `match'. That would be backward compatible, and we could see whether we like it enough to do things that way in `racket2'. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
On Sat, May 4, 2013 at 9:07 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Fri, 3 May 2013 17:29:52 -0400, Eli Barzilay wrote:
A few minutes ago, Robby Findler wrote:
FWIW, this was the bug in redex that prompted me to send this
message (it was there for some time since it wasn't a syntax error
it was similar in spirit to the code I posted; things broke
when #f was an argument)
[I think that it's good to have a much more relaxed policy about
breaking compatibility in cases like this: so far there was no real
code found that uses the feature, but there is one instance of code
that would get fixed by the change...]
Well, Ian provided an example from real code, right? Ian is willing to
change his code, but the code sounds real.
There's also the use in `unparse-pattern' in Redex. Maybe that's the
troublesome one that Robby has in mind changing (or he would be happy
to change it, obviously), but it's another real example.
No, that was not the example. The code I sent at the beginning of the
thread was an adjusted version of the bug that hid in Redex for, roughly,
months. It was a real bug and caused real problems and we knew something
was wrong but didn't find it for some time.
In other words, this isn't some made-up, code cleanliness-based request.
Robby
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
At Sat, 4 May 2013 09:15:22 -0500, Robby Findler wrote: On Sat, May 4, 2013 at 9:07 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 3 May 2013 17:29:52 -0400, Eli Barzilay wrote: A few minutes ago, Robby Findler wrote: FWIW, this was the bug in redex that prompted me to send this message (it was there for some time since it wasn't a syntax error it was similar in spirit to the code I posted; things broke when #f was an argument) [I think that it's good to have a much more relaxed policy about breaking compatibility in cases like this: so far there was no real code found that uses the feature, but there is one instance of code that would get fixed by the change...] Well, Ian provided an example from real code, right? Ian is willing to change his code, but the code sounds real. There's also the use in `unparse-pattern' in Redex. Maybe that's the troublesome one that Robby has in mind changing (or he would be happy to change it, obviously), but it's another real example. No, that was not the example. The code I sent at the beginning of the thread was an adjusted version of the bug that hid in Redex for, roughly, months. It was a real bug and caused real problems and we knew something was wrong but didn't find it for some time. In other words, this isn't some made-up, code cleanliness-based request. Yes, I understand that you faced a real bug. I hedged above on `unparse-pattern' not to suggest that your actual bug was uninteresting, but to suggest that I might misunderstand the relationship between the bug and the current state of our repository. All else being equal, I'm definitely in favor of a change to a sensible `else' for `match'. The else that isn't equal, however, is backward compatibility, and I think we're at the right point in our development cycle to defer backward incompatibilities to the next language --- hence my vote to defer. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
Matthew, Out of curiosity, could you explain why you'd prefer #:else everywhere instead of [else ...] ? Would such an #:else allow for multi-line bodies? On Sat, May 4, 2013 at 5:06 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Sat, 4 May 2013 09:15:22 -0500, Robby Findler wrote: On Sat, May 4, 2013 at 9:07 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 3 May 2013 17:29:52 -0400, Eli Barzilay wrote: A few minutes ago, Robby Findler wrote: FWIW, this was the bug in redex that prompted me to send this message (it was there for some time since it wasn't a syntax error it was similar in spirit to the code I posted; things broke when #f was an argument) [I think that it's good to have a much more relaxed policy about breaking compatibility in cases like this: so far there was no real code found that uses the feature, but there is one instance of code that would get fixed by the change...] Well, Ian provided an example from real code, right? Ian is willing to change his code, but the code sounds real. There's also the use in `unparse-pattern' in Redex. Maybe that's the troublesome one that Robby has in mind changing (or he would be happy to change it, obviously), but it's another real example. No, that was not the example. The code I sent at the beginning of the thread was an adjusted version of the bug that hid in Redex for, roughly, months. It was a real bug and caused real problems and we knew something was wrong but didn't find it for some time. In other words, this isn't some made-up, code cleanliness-based request. Yes, I understand that you faced a real bug. I hedged above on `unparse-pattern' not to suggest that your actual bug was uninteresting, but to suggest that I might misunderstand the relationship between the bug and the current state of our repository. All else being equal, I'm definitely in favor of a change to a sensible `else' for `match'. The else that isn't equal, however, is backward compatibility, and I think we're at the right point in our development cycle to defer backward incompatibilities to the next language --- hence my vote to defer. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
Okay, makes sense. Lets leave it alone. Robby On Sat, May 4, 2013 at 10:06 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Sat, 4 May 2013 09:15:22 -0500, Robby Findler wrote: On Sat, May 4, 2013 at 9:07 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 3 May 2013 17:29:52 -0400, Eli Barzilay wrote: A few minutes ago, Robby Findler wrote: FWIW, this was the bug in redex that prompted me to send this message (it was there for some time since it wasn't a syntax error it was similar in spirit to the code I posted; things broke when #f was an argument) [I think that it's good to have a much more relaxed policy about breaking compatibility in cases like this: so far there was no real code found that uses the feature, but there is one instance of code that would get fixed by the change...] Well, Ian provided an example from real code, right? Ian is willing to change his code, but the code sounds real. There's also the use in `unparse-pattern' in Redex. Maybe that's the troublesome one that Robby has in mind changing (or he would be happy to change it, obviously), but it's another real example. No, that was not the example. The code I sent at the beginning of the thread was an adjusted version of the bug that hid in Redex for, roughly, months. It was a real bug and caused real problems and we knew something was wrong but didn't find it for some time. In other words, this isn't some made-up, code cleanliness-based request. Yes, I understand that you faced a real bug. I hedged above on `unparse-pattern' not to suggest that your actual bug was uninteresting, but to suggest that I might misunderstand the relationship between the bug and the current state of our repository. All else being equal, I'm definitely in favor of a change to a sensible `else' for `match'. The else that isn't equal, however, is backward compatibility, and I think we're at the right point in our development cycle to defer backward incompatibilities to the next language --- hence my vote to defer. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
(that was assuming Ryan's assertion that [...]Matthew say that he would have used a keyword for `else` in `cond` if he had it to do over again, which seem to mean that even in Racket2 Matthew would prefer `#:else' over `[else ...]' ?) On Sat, May 4, 2013 at 5:14 PM, Laurent laurent.ors...@gmail.com wrote: Matthew, Out of curiosity, could you explain why you'd prefer #:else everywhere instead of [else ...] ? Would such an #:else allow for multi-line bodies? On Sat, May 4, 2013 at 5:06 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Sat, 4 May 2013 09:15:22 -0500, Robby Findler wrote: On Sat, May 4, 2013 at 9:07 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 3 May 2013 17:29:52 -0400, Eli Barzilay wrote: A few minutes ago, Robby Findler wrote: FWIW, this was the bug in redex that prompted me to send this message (it was there for some time since it wasn't a syntax error it was similar in spirit to the code I posted; things broke when #f was an argument) [I think that it's good to have a much more relaxed policy about breaking compatibility in cases like this: so far there was no real code found that uses the feature, but there is one instance of code that would get fixed by the change...] Well, Ian provided an example from real code, right? Ian is willing to change his code, but the code sounds real. There's also the use in `unparse-pattern' in Redex. Maybe that's the troublesome one that Robby has in mind changing (or he would be happy to change it, obviously), but it's another real example. No, that was not the example. The code I sent at the beginning of the thread was an adjusted version of the bug that hid in Redex for, roughly, months. It was a real bug and caused real problems and we knew something was wrong but didn't find it for some time. In other words, this isn't some made-up, code cleanliness-based request. Yes, I understand that you faced a real bug. I hedged above on `unparse-pattern' not to suggest that your actual bug was uninteresting, but to suggest that I might misunderstand the relationship between the bug and the current state of our repository. All else being equal, I'm definitely in favor of a change to a sensible `else' for `match'. The else that isn't equal, however, is backward compatibility, and I think we're at the right point in our development cycle to defer backward incompatibilities to the next language --- hence my vote to defer. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
I think the bad property is the shadowing of the else identifier and Matthew's point is that one way to avoid that is to not use an identifier at all. The racket2 wiki currently says try this out so I guess it isn't something people believe will definitely be better, but something to explore. Robby On Sat, May 4, 2013 at 10:33 AM, Laurent laurent.ors...@gmail.com wrote: (that was assuming Ryan's assertion that [...]Matthew say that he would have used a keyword for `else` in `cond` if he had it to do over again, which seem to mean that even in Racket2 Matthew would prefer `#:else' over `[else ...]' ?) On Sat, May 4, 2013 at 5:14 PM, Laurent laurent.ors...@gmail.com wrote: Matthew, Out of curiosity, could you explain why you'd prefer #:else everywhere instead of [else ...] ? Would such an #:else allow for multi-line bodies? On Sat, May 4, 2013 at 5:06 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Sat, 4 May 2013 09:15:22 -0500, Robby Findler wrote: On Sat, May 4, 2013 at 9:07 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 3 May 2013 17:29:52 -0400, Eli Barzilay wrote: A few minutes ago, Robby Findler wrote: FWIW, this was the bug in redex that prompted me to send this message (it was there for some time since it wasn't a syntax error it was similar in spirit to the code I posted; things broke when #f was an argument) [I think that it's good to have a much more relaxed policy about breaking compatibility in cases like this: so far there was no real code found that uses the feature, but there is one instance of code that would get fixed by the change...] Well, Ian provided an example from real code, right? Ian is willing to change his code, but the code sounds real. There's also the use in `unparse-pattern' in Redex. Maybe that's the troublesome one that Robby has in mind changing (or he would be happy to change it, obviously), but it's another real example. No, that was not the example. The code I sent at the beginning of the thread was an adjusted version of the bug that hid in Redex for, roughly, months. It was a real bug and caused real problems and we knew something was wrong but didn't find it for some time. In other words, this isn't some made-up, code cleanliness-based request. Yes, I understand that you faced a real bug. I hedged above on `unparse-pattern' not to suggest that your actual bug was uninteresting, but to suggest that I might misunderstand the relationship between the bug and the current state of our repository. All else being equal, I'm definitely in favor of a change to a sensible `else' for `match'. The else that isn't equal, however, is backward compatibility, and I think we're at the right point in our development cycle to defer backward incompatibilities to the next language --- hence my vote to defer. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
On 2013-05-04 10:36:14 -0500, Robby Findler wrote: The racket2 wiki currently says try this out so I guess it isn't something people believe will definitely be better, but something to explore. FWIW, Clojure uses keywords for `else` so there is some experience there: http://clojuredocs.org/clojure_core/clojure.core/cond Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
There will be people who see the long BNF for match in the Reference, and flee to the Guide to try to learn by example instead. Even when they later do read the Reference carefully, they'll be left with first impressions of idioms from the Guide. (I might be one of those people. Cough.) The Guide http://docs.racket-lang.org/guide/match.html uses `else` in a couple examples. Also, I somehow got the idea that `(var x)` was the only way to do what `else` can do by accident. So I don't _think_ I have any code that's buggy this way, or, which would break if the change were made, either way. I think. Until I saw your email I didn't appreciate why it would make sense to use `_`. Going forward I will. On Fri, May 3, 2013 at 9:39 AM, Robby Findler ro...@eecs.northwestern.edu wrote: [ for those that just want to see what I'm getting at, scroll to the end ] While the docs are clear (enough) on this point, I think it can be quite confusing. See if you spot the bug in this program: #lang racket (define (find-literals e) (define literals '()) (let loop ([e e]) (match e [`(λ (,x) ,e) (loop e)] [`(,e1 ,e2) (loop e1) (loop e2)] [(? symbol?) (void)] [else (cond [(member e literals) (void)] [else (set! literals (cons e literals))])])) literals) (module+ test (require rackunit) (check-equal? (find-literals '(λ (x) x)) '()) (check-equal? (find-literals '((λ (x) x) 1)) '(1)) (check-equal? (find-literals '((λ (x) x) #f)) '(#f))) Hint: the last test case fails. Second hint: if you switch it to use sets, it starts working. Third hint: this isn't about lists. :) The bug is that 'else' is treated as a variable in match, so it gets bound to #f, which shadows the else in the cond which is confusing. So, how about making match treat else specially? I don't ask this completely from outer space; there was a bug in Redex's random generation that was caused exactly by this shadowing of else. Robby _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
Oh, right! Thanks! I'll push something that explicitly mentions underscore and adjust the elses to use underscores. Robby On Sat, May 4, 2013 at 9:09 PM, Greg Hendershott greghendersh...@gmail.comwrote: There will be people who see the long BNF for match in the Reference, and flee to the Guide to try to learn by example instead. Even when they later do read the Reference carefully, they'll be left with first impressions of idioms from the Guide. (I might be one of those people. Cough.) The Guide http://docs.racket-lang.org/guide/match.html uses `else` in a couple examples. Also, I somehow got the idea that `(var x)` was the only way to do what `else` can do by accident. So I don't _think_ I have any code that's buggy this way, or, which would break if the change were made, either way. I think. Until I saw your email I didn't appreciate why it would make sense to use `_`. Going forward I will. On Fri, May 3, 2013 at 9:39 AM, Robby Findler ro...@eecs.northwestern.edu wrote: [ for those that just want to see what I'm getting at, scroll to the end ] While the docs are clear (enough) on this point, I think it can be quite confusing. See if you spot the bug in this program: #lang racket (define (find-literals e) (define literals '()) (let loop ([e e]) (match e [`(λ (,x) ,e) (loop e)] [`(,e1 ,e2) (loop e1) (loop e2)] [(? symbol?) (void)] [else (cond [(member e literals) (void)] [else (set! literals (cons e literals))])])) literals) (module+ test (require rackunit) (check-equal? (find-literals '(λ (x) x)) '()) (check-equal? (find-literals '((λ (x) x) 1)) '(1)) (check-equal? (find-literals '((λ (x) x) #f)) '(#f))) Hint: the last test case fails. Second hint: if you switch it to use sets, it starts working. Third hint: this isn't about lists. :) The bug is that 'else' is treated as a variable in match, so it gets bound to #f, which shadows the else in the cond which is confusing. So, how about making match treat else specially? I don't ask this completely from outer space; there was a bug in Redex's random generation that was caused exactly by this shadowing of else. Robby _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] else clauses: possible change to match?
[ for those that just want to see what I'm getting at, scroll to the end ] While the docs are clear (enough) on this point, I think it can be quite confusing. See if you spot the bug in this program: #lang racket (define (find-literals e) (define literals '()) (let loop ([e e]) (match e [`(λ (,x) ,e) (loop e)] [`(,e1 ,e2) (loop e1) (loop e2)] [(? symbol?) (void)] [else (cond [(member e literals) (void)] [else (set! literals (cons e literals))])])) literals) (module+ test (require rackunit) (check-equal? (find-literals '(λ (x) x)) '()) (check-equal? (find-literals '((λ (x) x) 1)) '(1)) (check-equal? (find-literals '((λ (x) x) #f)) '(#f))) Hint: the last test case fails. Second hint: if you switch it to use sets, it starts working. Third hint: this isn't about lists. :) The bug is that 'else' is treated as a variable in match, so it gets bound to #f, which shadows the else in the cond which is confusing. So, how about making match treat else specially? I don't ask this completely from outer space; there was a bug in Redex's random generation that was caused exactly by this shadowing of else. Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
That one is twisted indeed, if you forget about how `else' must be written in `match' (which I had, not using match too much). I was thinking about issuing a warning when a syntax-parameter gets shadowed (if that is even catchable). Then suddenly I realized Racket doesn't do warnings. (Is there a reason for that?) Laurent On Fri, May 3, 2013 at 3:39 PM, Robby Findler ro...@eecs.northwestern.eduwrote: [ for those that just want to see what I'm getting at, scroll to the end ] While the docs are clear (enough) on this point, I think it can be quite confusing. See if you spot the bug in this program: #lang racket (define (find-literals e) (define literals '()) (let loop ([e e]) (match e [`(λ (,x) ,e) (loop e)] [`(,e1 ,e2) (loop e1) (loop e2)] [(? symbol?) (void)] [else (cond [(member e literals) (void)] [else (set! literals (cons e literals))])])) literals) (module+ test (require rackunit) (check-equal? (find-literals '(λ (x) x)) '()) (check-equal? (find-literals '((λ (x) x) 1)) '(1)) (check-equal? (find-literals '((λ (x) x) #f)) '(#f))) Hint: the last test case fails. Second hint: if you switch it to use sets, it starts working. Third hint: this isn't about lists. :) The bug is that 'else' is treated as a variable in match, so it gets bound to #f, which shadows the else in the cond which is confusing. So, how about making match treat else specially? I don't ask this completely from outer space; there was a bug in Redex's random generation that was caused exactly by this shadowing of else. Robby _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
We do have warnings for things like the optimizer detecting a bad
application of a function, for example, but they go into the logger and you
have to say the magic words (open sesame?) to get them out.
For this kind of thing, my preference would be to change match than to
issue a warning. I don't like warnings that are basically admitting
weaknesses in the language design Of course, changing a core thing like
that may be more trouble than it is worth, due to backwards compatibility
concerns, which is why I think it is worth raising here to see what others
think.
Alternatively, we could revisit 'else' in racket2 and leave racket alone.
Robby
On Friday, May 3, 2013, Laurent wrote:
That one is twisted indeed, if you forget about how `else' must be written
in `match' (which I had, not using match too much).
I was thinking about issuing a warning when a syntax-parameter gets
shadowed (if that is even catchable).
Then suddenly I realized Racket doesn't do warnings. (Is there a reason
for that?)
Laurent
On Fri, May 3, 2013 at 3:39 PM, Robby Findler
ro...@eecs.northwestern.edujavascript:_e({}, 'cvml',
'ro...@eecs.northwestern.edu');
wrote:
[ for those that just want to see what I'm getting at, scroll to the end ]
While the docs are clear (enough) on this point, I think it can be quite
confusing. See if you spot the bug in this program:
#lang racket
(define (find-literals e)
(define literals '())
(let loop ([e e])
(match e
[`(λ (,x) ,e)
(loop e)]
[`(,e1 ,e2)
(loop e1)
(loop e2)]
[(? symbol?) (void)]
[else
(cond
[(member e literals)
(void)]
[else
(set! literals (cons e literals))])]))
literals)
(module+ test
(require rackunit)
(check-equal? (find-literals '(λ (x) x)) '())
(check-equal? (find-literals '((λ (x) x) 1)) '(1))
(check-equal? (find-literals '((λ (x) x) #f)) '(#f)))
Hint: the last test case fails. Second hint: if you switch it to use
sets, it starts working. Third hint: this isn't about lists. :)
The bug is that 'else' is treated as a variable in match, so it gets
bound to #f, which shadows the else in the cond which is confusing.
So, how about making match treat else specially?
I don't ask this completely from outer space; there was a bug in Redex's
random generation that was caused exactly by this shadowing of else.
Robby
_
Racket Developers list:
http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
On Fri, May 3, 2013 at 4:22 PM, Robby Findler ro...@eecs.northwestern.eduwrote: I don't like warnings that are basically admitting weaknesses in the language design Ah, that's the answer my subconscious was seeking when I wondered about Racket warnings. Good point! FWIW, I'd vote (with my voting weight being around the epsilons) for a change in else/match too, as I hardly see someone binding else in match intentionally, and hoping to get away with it. At best, some old buggy programs will magically start working ;) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
On Fri, May 3, 2013 at 10:22 AM, Robby Findler ro...@eecs.northwestern.edu wrote: For this kind of thing, my preference would be to change match than to issue a warning. I don't like warnings that are basically admitting weaknesses in the language design Of course, changing a core thing like that may be more trouble than it is worth, due to backwards compatibility concerns, which is why I think it is worth raising here to see what others think. I'm happy to make this change to `match`, except that I've heard Matthew say that he would have used a keyword for `else` in `cond` if he had it to do over again, and I wouldn't want to change one way, and then change back. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
That's my take too, but we should really be careful about changes at this
level.
Robby
On Friday, May 3, 2013, Laurent wrote:
On Fri, May 3, 2013 at 4:22 PM, Robby Findler
ro...@eecs.northwestern.edujavascript:_e({}, 'cvml',
'ro...@eecs.northwestern.edu');
wrote:
I don't like warnings that are basically admitting weaknesses in the
language design
Ah, that's the answer my subconscious was seeking when I wondered about
Racket warnings. Good point!
FWIW, I'd vote (with my voting weight being around the epsilons) for a
change in else/match too, as I hardly see someone binding else in match
intentionally, and hoping to get away with it.
At best, some old buggy programs will magically start working ;)
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
Cond's else cannot change. I agree that that's what I would change if I could have it back to do it over, but we cannot. That's the way to perhaps be thinking about racket2, tho. Robby On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote: On Fri, May 3, 2013 at 10:22 AM, Robby Findler ro...@eecs.northwestern.edu javascript:; wrote: For this kind of thing, my preference would be to change match than to issue a warning. I don't like warnings that are basically admitting weaknesses in the language design Of course, changing a core thing like that may be more trouble than it is worth, due to backwards compatibility concerns, which is why I think it is worth raising here to see what others think. I'm happy to make this change to `match`, except that I've heard Matthew say that he would have used a keyword for `else` in `cond` if he had it to do over again, and I wouldn't want to change one way, and then change back. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
Right, I agree with this. My question is basically: are we going to, in the reasonably near future, be encouraging people to program in a `#lang racket2` where `cond` works differently, in which case it doesn't seem worth it to change `match`. Otherwise, I'll do this now. Sam On Fri, May 3, 2013 at 10:42 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Cond's else cannot change. I agree that that's what I would change if I could have it back to do it over, but we cannot. That's the way to perhaps be thinking about racket2, tho. Robby On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote: On Fri, May 3, 2013 at 10:22 AM, Robby Findler ro...@eecs.northwestern.edu wrote: For this kind of thing, my preference would be to change match than to issue a warning. I don't like warnings that are basically admitting weaknesses in the language design Of course, changing a core thing like that may be more trouble than it is worth, due to backwards compatibility concerns, which is why I think it is worth raising here to see what others think. I'm happy to make this change to `match`, except that I've heard Matthew say that he would have used a keyword for `else` in `cond` if he had it to do over again, and I wouldn't want to change one way, and then change back. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
Given that we don't yet even have a prototype of racket2, I'm going to guess that near isn't all that near. IMO, there are other big things that we should be focused on going first (notably the package system). Just to check again: Is no one concerned with the backwards incompatibility issue? Robby On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote: Right, I agree with this. My question is basically: are we going to, in the reasonably near future, be encouraging people to program in a `#lang racket2` where `cond` works differently, in which case it doesn't seem worth it to change `match`. Otherwise, I'll do this now. Sam On Fri, May 3, 2013 at 10:42 AM, Robby Findler ro...@eecs.northwestern.edu javascript:; wrote: Cond's else cannot change. I agree that that's what I would change if I could have it back to do it over, but we cannot. That's the way to perhaps be thinking about racket2, tho. Robby On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote: On Fri, May 3, 2013 at 10:22 AM, Robby Findler ro...@eecs.northwestern.edu javascript:; wrote: For this kind of thing, my preference would be to change match than to issue a warning. I don't like warnings that are basically admitting weaknesses in the language design Of course, changing a core thing like that may be more trouble than it is worth, due to backwards compatibility concerns, which is why I think it is worth raising here to see what others think. I'm happy to make this change to `match`, except that I've heard Matthew say that he would have used a keyword for `else` in `cond` if he had it to do over again, and I wouldn't want to change one way, and then change back. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
I've used else as a catch-all binding in match. Yes, it's not the best practice, but I think since I've done it, other people must have done it too. This could annoy them. -Ian - Original Message - From: Robby Findler ro...@eecs.northwestern.edu To: Sam Tobin-Hochstadt sa...@ccs.neu.edu Cc: dev@racket-lang.org Sent: Friday, May 3, 2013 11:04:27 AM GMT -05:00 US/Canada Eastern Subject: Re: [racket-dev] else clauses: possible change to match? Given that we don't yet even have a prototype of racket2, I'm going to guess that near isn't all that near. IMO, there are other big things that we should be focused on going first (notably the package system). Just to check again: Is no one concerned with the backwards incompatibility issue? Robby On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote: Right, I agree with this. My question is basically: are we going to, in the reasonably near future, be encouraging people to program in a `#lang racket2` where `cond` works differently, in which case it doesn't seem worth it to change `match`. Otherwise, I'll do this now. Sam On Fri, May 3, 2013 at 10:42 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Cond's else cannot change. I agree that that's what I would change if I could have it back to do it over, but we cannot. That's the way to perhaps be thinking about racket2, tho. Robby On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote: On Fri, May 3, 2013 at 10:22 AM, Robby Findler ro...@eecs.northwestern.edu wrote: For this kind of thing, my preference would be to change match than to issue a warning. I don't like warnings that are basically admitting weaknesses in the language design Of course, changing a core thing like that may be more trouble than it is worth, due to backwards compatibility concerns, which is why I think it is worth raising here to see what others think. I'm happy to make this change to `match`, except that I've heard Matthew say that he would have used a keyword for `else` in `cond` if he had it to do over again, and I wouldn't want to change one way, and then change back. Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
Can you point to some examples? Note that you can still use else, as long as you don't refer to it as a variable. On Friday, May 3, 2013, J. Ian Johnson wrote: I've used else as a catch-all binding in match. Yes, it's not the best practice, but I think since I've done it, other people must have done it too. This could annoy them. -Ian - Original Message - From: Robby Findler ro...@eecs.northwestern.edu javascript:; To: Sam Tobin-Hochstadt sa...@ccs.neu.edu javascript:; Cc: dev@racket-lang.org javascript:; Sent: Friday, May 3, 2013 11:04:27 AM GMT -05:00 US/Canada Eastern Subject: Re: [racket-dev] else clauses: possible change to match? Given that we don't yet even have a prototype of racket2, I'm going to guess that near isn't all that near. IMO, there are other big things that we should be focused on going first (notably the package system). Just to check again: Is no one concerned with the backwards incompatibility issue? Robby On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote: Right, I agree with this. My question is basically: are we going to, in the reasonably near future, be encouraging people to program in a `#lang racket2` where `cond` works differently, in which case it doesn't seem worth it to change `match`. Otherwise, I'll do this now. Sam On Fri, May 3, 2013 at 10:42 AM, Robby Findler ro...@eecs.northwestern.edu javascript:; wrote: Cond's else cannot change. I agree that that's what I would change if I could have it back to do it over, but we cannot. That's the way to perhaps be thinking about racket2, tho. Robby On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote: On Fri, May 3, 2013 at 10:22 AM, Robby Findler ro...@eecs.northwestern.edu javascript:; wrote: For this kind of thing, my preference would be to change match than to issue a warning. I don't like warnings that are basically admitting weaknesses in the language design Of course, changing a core thing like that may be more trouble than it is worth, due to backwards compatibility concerns, which is why I think it is worth raising here to see what others think. I'm happy to make this change to `match`, except that I've heard Matthew say that he would have used a keyword for `else` in `cond` if he had it to do over again, and I wouldn't want to change one way, and then change back. Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
A few minutes ago, Robby Findler wrote: Given that we don't yet even have a prototype of racket2, I'm going to guess that near isn't all that near. IMO, there are other big things that we should be focused on going first (notably the package system). +1, since the damage would be that people will need to convert uses `match', but that'll be minor compared to `cond'. A few minutes ago, J. Ian Johnson wrote: I've used else as a catch-all binding in match. Yes, it's not the best practice, but I think since I've done it, other people must have done it too. This could annoy them. Do you have an actual use that would *break*? That is, something like (match x ... [else else]) -- ((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] else clauses: possible change to match?
Nothing readily available. I commonly use a shimmed match that gives better match failure errors that help me pinpoint a problem (though it's not for everyone): (define-syntax (matche stx) (syntax-case stx () [(_ e [p rhs] ...) #`(matche e [p rhs ...] [else (error 'bad-match ~a didn't match in ~a else '#,stx)])])) A macro is easy enough to change. I'm not saying to stay the backwards incompatible change because of me (and I don't use else like this anymore). I'm just noting that this seems like a plausible pattern out there. -Ian - Original Message - From: Robby Findler ro...@eecs.northwestern.edu To: J. Ian Johnson i...@ccs.neu.edu Cc: Robby Findler ro...@eecs.northwestern.edu, dev@racket-lang.org, Sam Tobin-Hochstadt sa...@ccs.neu.edu Sent: Friday, May 3, 2013 11:12:34 AM GMT -05:00 US/Canada Eastern Subject: Re: else clauses: possible change to match? Can you point to some examples? Note that you can still use else, as long as you don't refer to it as a variable. On Friday, May 3, 2013, J. Ian Johnson wrote: I've used else as a catch-all binding in match. Yes, it's not the best practice, but I think since I've done it, other people must have done it too. This could annoy them. -Ian - Original Message - From: Robby Findler ro...@eecs.northwestern.edu To: Sam Tobin-Hochstadt sa...@ccs.neu.edu Cc: dev@racket-lang.org Sent: Friday, May 3, 2013 11:04:27 AM GMT -05:00 US/Canada Eastern Subject: Re: [racket-dev] else clauses: possible change to match? Given that we don't yet even have a prototype of racket2, I'm going to guess that near isn't all that near. IMO, there are other big things that we should be focused on going first (notably the package system). Just to check again: Is no one concerned with the backwards incompatibility issue? Robby On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote: Right, I agree with this. My question is basically: are we going to, in the reasonably near future, be encouraging people to program in a `#lang racket2` where `cond` works differently, in which case it doesn't seem worth it to change `match`. Otherwise, I'll do this now. Sam On Fri, May 3, 2013 at 10:42 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Cond's else cannot change. I agree that that's what I would change if I could have it back to do it over, but we cannot. That's the way to perhaps be thinking about racket2, tho. Robby On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote: On Fri, May 3, 2013 at 10:22 AM, Robby Findler ro...@eecs.northwestern.edu wrote: For this kind of thing, my preference would be to change match than to issue a warning. I don't like warnings that are basically admitting weaknesses in the language design Of course, changing a core thing like that may be more trouble than it is worth, due to backwards compatibility concerns, which is why I think it is worth raising here to see what others think. I'm happy to make this change to `match`, except that I've heard Matthew say that he would have used a keyword for `else` in `cond` if he had it to do over again, and I wouldn't want to change one way, and then change back. Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
On 05/03/2013 11:12 AM, Robby Findler wrote: Can you point to some examples? Note that you can still use else, as long as you don't refer to it as a variable. Just to check: If match treats else specially, it should only accept it as the entire pattern. For example, the following should be an illegal use of else: (match x [(list 'if test then else) ___]) Right? (BTW, I may have written exactly the code above. I need to check.) Ryan On Friday, May 3, 2013, J. Ian Johnson wrote: I've used else as a catch-all binding in match. Yes, it's not the best practice, but I think since I've done it, other people must have done it too. This could annoy them. -Ian - Original Message - From: Robby Findler ro...@eecs.northwestern.edu javascript:; To: Sam Tobin-Hochstadt sa...@ccs.neu.edu javascript:; Cc: dev@racket-lang.org javascript:; Sent: Friday, May 3, 2013 11:04:27 AM GMT -05:00 US/Canada Eastern Subject: Re: [racket-dev] else clauses: possible change to match? Given that we don't yet even have a prototype of racket2, I'm going to guess that near isn't all that near. IMO, there are other big things that we should be focused on going first (notably the package system). Just to check again: Is no one concerned with the backwards incompatibility issue? Robby On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote: Right, I agree with this. My question is basically: are we going to, in the reasonably near future, be encouraging people to program in a `#lang racket2` where `cond` works differently, in which case it doesn't seem worth it to change `match`. Otherwise, I'll do this now. Sam On Fri, May 3, 2013 at 10:42 AM, Robby Findler ro...@eecs.northwestern.edu javascript:; wrote: Cond's else cannot change. I agree that that's what I would change if I could have it back to do it over, but we cannot. That's the way to perhaps be thinking about racket2, tho. Robby On Friday, May 3, 2013, Sam Tobin-Hochstadt wrote: On Fri, May 3, 2013 at 10:22 AM, Robby Findler ro...@eecs.northwestern.edu javascript:; wrote: For this kind of thing, my preference would be to change match than to issue a warning. I don't like warnings that are basically admitting weaknesses in the language design Of course, changing a core thing like that may be more trouble than it is worth, due to backwards compatibility concerns, which is why I think it is worth raising here to see what others think. I'm happy to make this change to `match`, except that I've heard Matthew say that he would have used a keyword for `else` in `cond` if he had it to do over again, and I wouldn't want to change one way, and then change back. Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
On 05/03/2013 09:12 AM, Eli Barzilay wrote: A few minutes ago, Robby Findler wrote: Given that we don't yet even have a prototype of racket2, I'm going to guess that near isn't all that near. IMO, there are other big things that we should be focused on going first (notably the package system). +1, since the damage would be that people will need to convert uses `match', but that'll be minor compared to `cond'. +1, same reasons. When I don't use match for a while, the first time I use it, I almost always write [else ...] as the last clause. Then I catch myself and replace `else' with `_'. I started being careful about catch-all cases in `match' when I wrote an expression similar to this: (match a [(list x) #t] [else (case (first a) [(6) #f] [else #t])]) got this error: case: bad syntax (not a datum sequence) in: else and was completely baffled for a long time. A few minutes ago, J. Ian Johnson wrote: I've used else as a catch-all binding in match. Yes, it's not the best practice, but I think since I've done it, other people must have done it too. This could annoy them. Do you have an actual use that would *break*? That is, something like (match x ... [else else]) I'll bet almost every use of just `else' as a pattern in the wild doesn't have `else' in the body because it's intended to be a catch-all case. If it does have `else' in the body, it's almost certainly in a `cond' or a `case', which is either an error or hideous style. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
A few minutes ago, Robby Findler wrote: FWIW, this was the bug in redex that prompted me to send this message (it was there for some time since it wasn't a syntax error it was similar in spirit to the code I posted; things broke when #f was an argument) [I think that it's good to have a much more relaxed policy about breaking compatibility in cases like this: so far there was no real code found that uses the feature, but there is one instance of code that would get fixed by the change...] -- ((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
