On Fri, Sep 30, 2011 at 12:40:49PM -0500, Robby Findler wrote: > On Fri, Sep 30, 2011 at 12:32 PM, Neil Van Dyke <n...@neilvandyke.org> wrote: > > Robby Findler wrote at 09/30/2011 01:05 PM: > >> > >> On Fri, Sep 30, 2011 at 12:01 PM, John Clements > >> <cleme...@brinckerhoff.org> wrote: > >> > >>> > >>> In my world, a change will fall into the "yes, racket is a rapidly > >>> changing language" bin; > >>> it's not unusual for much of my old code to be broken. > >>> > >> > >> I realize this is a meta question, but is this the world we really > >> want Racket to be in? > >> > > > > I want it to be stable (backward-compatible changes in general). However, I > > also want it to continue to innovate. I think that the interactivity > > between the developers and users of the platform permits us to have both. > > Sometimes, you can simply ask "hey, is it OK with everyone if I break > > such-and-such slightly, requiring you to make a small code change?", and if > > the answer is yes, you collectively save a person-week of work and also > > avoid some legacy cruft. > > In this case, the two alternatives are the same amount of work, if I > understand correctly. > > > On the other hand, if you want Racket to be an exercise and showcase for > > perfect backward compatibility, that might be interesting. Perhaps someone > > can find some novel techniques to help do that, and some way of > > demonstrating the contribution (seamless backward compatibility throughout > > evolution, without some cost that systems traditionally incur to satisfy > > that). > > I don't think that we're even close to this. :)
It might be something like #lang racket-version6.4.6 with conventions about bug-fixes vs specification changes. And that would have to remember versions of libraries as well. But it wouldn't be trivial. -- hendrik _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
