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

On Monday, May 6, 2013, Jay McCarthy wrote:

> On Mon, May 6, 2013 at 7:29 AM, Matthew Flatt <mflatt at cs.utah.edu<javascript:;>>
> wrote:
> > 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<javascript:;>>
> 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'.
>
> FWIW, I don't find "#lang racket2" ugly.
>
> >> 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.
>
> I agree that most people probably wouldn't do it, but I think having
> the infrastructure in place would be very valuable, because when you
> find that you code is broken, you can look up what version of Racket
> was released at the time and get it working right away, then look
> through the compatibility modules to port your code.
>
>
We currently have a path for this: download the old version.

Do you think we can do substantially better than that with a reasonable
amount of effort?

FWIW, I think that there are two significant advantages to using a 5.3.1
compatibility module in 5.3.4 (or whatever):

- bug fixes (esp in the compiler and runtime system)
- eases porting (as you can move files piecemeal)

My worry is on the effort side.

Robby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130506/94788e78/attachment-0001.html>