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

At Mon, 6 May 2013 07:02:47 -0600, Jay McCarthy wrote:
> On Mon, May 6, 2013 at 6:52 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> >> 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 meaning of "#lang racket" currently depends on its context because
> we make incompatible changes of any kind. (Even adding a single
> binding is incompatible with some uses like (require racket
> my/library).)

Granted.

Still, there are many programs that start `#lang racket' that are
well-defined because they don't depend on the differences across
versions. As a practical matter, we try to limit differences in
`racket' to make that happen as much as possible, and I think we should
continue to move even more in the direction of making modules less
dependent on implicit version context.

For the scale of changes that we want to make for `racket2', the number
of programs that would be the same with `#lang racket' and `#lang
racket2' will be drastically smaller than the number of `#lang racket'
programs that work across versions --- so much that I don't currently
believe it's practical to call both languages `racket'.

> I think that it is fine for #lang racket to continue to change in this
> way. The problem I see us as needing to solve is how to help people
> deal with incompatible changes. One idea is to create a system whereby
> (require v5.2.1/racket/list) is the interface to racket/list from
> 5.2.1 and #lang v5.2.1/racket is the racket from that version. Most of
> these versions would just be about hiding some bindings, but it lays
> the framework for more exhaustive changes. I think it would be easy to
> maintain these, because most deltas are small. But as they become more
> complex and less used, we can spin them out to packages to keep the
> main repo clean.

That sounds like a good approach for dealing with the finer differences
among versions and for writing code that last forever.

I think we'll have a hard time getting programmers to write versions in
all useful code, though. If that's the case, we're left having to make
some compromise on module/language changes versus compatibility for
useful code.