<br><br>On Monday, May 6, 2013, Jay McCarthy wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, May 6, 2013 at 7:29 AM, Matthew Flatt <<a href="javascript:;" onclick="_e(event, 'cvml', 'mflatt@cs.utah.edu')">mflatt@cs.utah.edu</a>> wrote:<br>
> At Mon, 6 May 2013 07:02:47 -0600, Jay McCarthy wrote:<br>
>> On Mon, May 6, 2013 at 6:52 AM, Matthew Flatt <<a href="javascript:;" onclick="_e(event, 'cvml', 'mflatt@cs.utah.edu')">mflatt@cs.utah.edu</a>> wrote:<br>
>> >> 3. And a side-comment: I hope that there will be something better<br>
>> >> than actual `racket2' used in code...<br>
>> ><br>
>> > Suggestions are welcome.<br>
>> ><br>
>> >> Maybe rename the current one<br>
>> >> to `racket1' and possibly have code in packages use that unless<br>
>> >> it's declared new somehow?<br>
>> ><br>
>> > Surely the meaning of `#lang racket' shouldn't depend on its context<br>
>> > --- otherwise we're moving back toward the world where no fragment of<br>
>> > code has a useful meaning unless you know its full context.<br>
>><br>
>> The meaning of "#lang racket" currently depends on its context because<br>
>> we make incompatible changes of any kind. (Even adding a single<br>
>> binding is incompatible with some uses like (require racket<br>
>> my/library).)<br>
><br>
> Granted.<br>
><br>
> Still, there are many programs that start `#lang racket' that are<br>
> well-defined because they don't depend on the differences across<br>
> versions. As a practical matter, we try to limit differences in<br>
> `racket' to make that happen as much as possible, and I think we should<br>
> continue to move even more in the direction of making modules less<br>
> dependent on implicit version context.<br>
><br>
> For the scale of changes that we want to make for `racket2', the number<br>
> of programs that would be the same with `#lang racket' and `#lang<br>
> racket2' will be drastically smaller than the number of `#lang racket'<br>
> programs that work across versions --- so much that I don't currently<br>
> believe it's practical to call both languages `racket'.<br>
<br>
FWIW, I don't find "#lang racket2" ugly.<br>
<br>
>> I think that it is fine for #lang racket to continue to change in this<br>
>> way. The problem I see us as needing to solve is how to help people<br>
>> deal with incompatible changes. One idea is to create a system whereby<br>
>> (require v5.2.1/racket/list) is the interface to racket/list from<br>
>> 5.2.1 and #lang v5.2.1/racket is the racket from that version. Most of<br>
>> these versions would just be about hiding some bindings, but it lays<br>
>> the framework for more exhaustive changes. I think it would be easy to<br>
>> maintain these, because most deltas are small. But as they become more<br>
>> complex and less used, we can spin them out to packages to keep the<br>
>> main repo clean.<br>
><br>
> That sounds like a good approach for dealing with the finer differences<br>
> among versions and for writing code that last forever.<br>
><br>
> I think we'll have a hard time getting programmers to write versions in<br>
> all useful code, though. If that's the case, we're left having to make<br>
> some compromise on module/language changes versus compatibility for<br>
> useful code.<br>
<br>
I agree that most people probably wouldn't do it, but I think having<br>
the infrastructure in place would be very valuable, because when you<br>
find that you code is broken, you can look up what version of Racket<br>
was released at the time and get it working right away, then look<br>
through the compatibility modules to port your code.<br>
<br></blockquote><div><br></div><div>We currently have a path for this: download the old version.</div><div><br></div><div>Do you think we can do substantially better than that with a reasonable amount of effort?</div><div>
<br></div><div>FWIW, I think that there are two significant advantages to using a 5.3.1 compatibility module in 5.3.4 (or whatever):</div><div><br></div><div>- bug fixes (esp in the compiler and runtime system)</div><div>
- eases porting (as you can move files piecemeal)</div><div><br></div><div>My worry is on the effort side.</div><div><br></div><div>Robby</div><div> </div>