[racket-dev] else clauses: possible change to match?

At Sun, 5 May 2013 12:03:59 -0400, Eli Barzilay 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?

I think the use case for identifiers is when you have an extensible
position in a syntactic form. Those are actually more common, I think.

The simplest kind of extensible position is an expression position,
where an identifier bound to a syntactic form is a kind of
production-selecting keyword. Along similar lines, using identifiers
for `init', `public', etc. in a `class' make sense to me, because those
appear in a position that is supposed to accommodate extension.

In contrast, you can't use a macro that expands to `else' in the
left-hand side of a `cond' clause; the "else"-ness of a `cond' clause
is not syntactically extensible. Non-extensibility is also a feature of
other places where we use keywords in a syntactic form, such as
`#:when' in `for' or `#:property' in `struct'.


> 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...

Anything is open for discussion, but speaking for myself, I'm not
interested in revisiting keyword syntax or case sensitivity.


> 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 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

Ian wrote, "I commonly use...", which gave me the opposite impression.

> and the redex
> use is exactly what would get unbroken

The use in `redex' that I pointed out was a place where changing
`match' made redex' not compile. (It was a different place than Robby
originally described, although Robby has now changed the second place,
too.)

Both Ian and Robby are happy to change their code. Then again, the dev
mailing list isn't the target audience for backward compatibility.