[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.orseau at 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.orseau at 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 <mflatt at 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 <mflatt at 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
> >>>
> >>
> >>
> >