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

On Mon, May 6, 2013 at 7:29 AM, Matthew Flatt <mflatt at cs.utah.edu> 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> 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.

Jay

--
Jay McCarthy <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93