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 <ro...@eecs.northwestern.edu> wrote: > > > On Monday, May 6, 2013, Jay McCarthy wrote: >> >> On Mon, May 6, 2013 at 7:29 AM, Matthew Flatt <mfl...@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 <mfl...@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 <j...@cs.byu.edu> Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _________________________ Racket Developers list: http://lists.racket-lang.org/dev