[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.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
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130504/eec6a8b6/attachment.html>