<div dir="ltr">As a generalization, maybe Racket2 could keep the invariant "`#:else' is the absorbing (default) case of any multi-arm form" ? <div><div class="gmail_extra"> <div class="gmail_quote">On Sun, May 5, 2013 at 4:30 PM, Matthew Flatt <<a href="mailto:mflatt@cs.utah.edu" target="_blank">mflatt@cs.utah.edu</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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. <div class="HOEnZb"><div class="h5"> 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 <<a href="mailto:laurent.orseau@gmail.com">laurent.orseau@gmail.com</a>> 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 <<a href="mailto:laurent.orseau@gmail.com">laurent.orseau@gmail.com</a>> 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 <<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>> wrote: > >> > >>> At Sat, 4 May 2013 09:15:22 -0500, Robby Findler wrote: > >>> > On Sat, May 4, 2013 at 9:07 AM, Matthew Flatt <<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>> > >>> 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: > >>> <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> > >>> > >> > >> > > </div></div></blockquote></div> </div></div></div>