[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 <eli at 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