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

I think the effort would be pretty modest, on the order of writing a test case.

For instance, if we added a binding in 5.4.1 relative to 5.3.99, then
we just need:

#lang racket
(require v5.4.1/racket)
(provide (except-out (all-from-out v5.4.1/racket) new-thing))

which doesn't seem to intense.

Jay


On Mon, May 6, 2013 at 7:41 AM, Robby Findler
<robby at eecs.northwestern.edu> wrote:
>
>
> On Monday, May 6, 2013, Jay McCarthy wrote:
>>
>> 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.
>>
>
> 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
>



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