On Monday, May 6, 2013, Jay McCarthy wrote: > On Mon, May 6, 2013 at 7:29 AM, Matthew Flatt > <mfl...@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 > >> <mfl...@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
_________________________ Racket Developers list: http://lists.racket-lang.org/dev