<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 &lt;<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;mflatt@cs.utah.edu&#39;)">mflatt@cs.utah.edu</a>&gt; wrote:<br>

&gt; At Mon, 6 May 2013 07:02:47 -0600, Jay McCarthy wrote:<br>
&gt;&gt; On Mon, May 6, 2013 at 6:52 AM, Matthew Flatt &lt;<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;mflatt@cs.utah.edu&#39;)">mflatt@cs.utah.edu</a>&gt; wrote:<br>
&gt;&gt; &gt;&gt; 3. And a side-comment: I hope that there will be something better<br>
&gt;&gt; &gt;&gt;    than actual `racket2&#39; used in code...<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Suggestions are welcome.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt;    Maybe rename the current one<br>
&gt;&gt; &gt;&gt;    to `racket1&#39; and possibly have code in packages use that unless<br>
&gt;&gt; &gt;&gt;    it&#39;s declared new somehow?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Surely the meaning of `#lang racket&#39; shouldn&#39;t depend on its context<br>
&gt;&gt; &gt; --- otherwise we&#39;re moving back toward the world where no fragment of<br>
&gt;&gt; &gt; code has a useful meaning unless you know its full context.<br>
&gt;&gt;<br>
&gt;&gt; The meaning of &quot;#lang racket&quot; currently depends on its context because<br>
&gt;&gt; we make incompatible changes of any kind. (Even adding a single<br>
&gt;&gt; binding is incompatible with some uses like (require racket<br>
&gt;&gt; my/library).)<br>
&gt;<br>
&gt; Granted.<br>
&gt;<br>
&gt; Still, there are many programs that start `#lang racket&#39; that are<br>
&gt; well-defined because they don&#39;t depend on the differences across<br>
&gt; versions. As a practical matter, we try to limit differences in<br>
&gt; `racket&#39; to make that happen as much as possible, and I think we should<br>
&gt; continue to move even more in the direction of making modules less<br>
&gt; dependent on implicit version context.<br>
&gt;<br>
&gt; For the scale of changes that we want to make for `racket2&#39;, the number<br>
&gt; of programs that would be the same with `#lang racket&#39; and `#lang<br>
&gt; racket2&#39; will be drastically smaller than the number of `#lang racket&#39;<br>
&gt; programs that work across versions --- so much that I don&#39;t currently<br>
&gt; believe it&#39;s practical to call both languages `racket&#39;.<br>
<br>
FWIW, I don&#39;t find &quot;#lang racket2&quot; ugly.<br>
<br>
&gt;&gt; I think that it is fine for #lang racket to continue to change in this<br>
&gt;&gt; way. The problem I see us as needing to solve is how to help people<br>
&gt;&gt; deal with incompatible changes. One idea is to create a system whereby<br>
&gt;&gt; (require v5.2.1/racket/list) is the interface to racket/list from<br>
&gt;&gt; 5.2.1 and #lang v5.2.1/racket is the racket from that version. Most of<br>
&gt;&gt; these versions would just be about hiding some bindings, but it lays<br>
&gt;&gt; the framework for more exhaustive changes. I think it would be easy to<br>
&gt;&gt; maintain these, because most deltas are small. But as they become more<br>
&gt;&gt; complex and less used, we can spin them out to packages to keep the<br>
&gt;&gt; main repo clean.<br>
&gt;<br>
&gt; That sounds like a good approach for dealing with the finer differences<br>
&gt; among versions and for writing code that last forever.<br>
&gt;<br>
&gt; I think we&#39;ll have a hard time getting programmers to write versions in<br>
&gt; all useful code, though. If that&#39;s the case, we&#39;re left having to make<br>
&gt; some compromise on module/language changes versus compatibility for<br>
&gt; useful code.<br>
<br>
I agree that most people probably wouldn&#39;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>