<br><br>On Saturday, October 1, 2011, Neil Toronto &lt;<a href="mailto:neil.toronto@gmail.com">neil.toronto@gmail.com</a>&gt; wrote:<br>&gt; On 10/01/2011 10:44 AM, Neil Van Dyke wrote:<br>&gt;&gt;<br>&gt;&gt; Neil Toronto wrote at 10/01/2011 12:15 PM:<br>
&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; 2. Whether to call the new library &quot;plot&quot; (rather than, say, &quot;plot2&quot; or<br>&gt;&gt;&gt;&gt; &quot;newimprovedsuperplot2000&quot;).<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Yep. That&#39;s part of the main question.<br>
&gt;&gt;<br>&gt;&gt; [...]<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; If the answer to #2 is &quot;the new library is called &#39;plot&#39;&quot;, then the<br>&gt;&gt;&gt; answer to #4 is &quot;you have to change (require plot) to (require<br>
&gt;&gt;&gt; plot/compat)&quot;. And then everything should work.<br>&gt;&gt;<br>&gt;&gt; Thanks, Neil T.<br>&gt;&gt;<br>&gt;&gt; If that&#39;s a big point of contention, then would everyone be happy either<br>&gt;&gt; with one of the following?<br>
&gt;&gt;<br>&gt;&gt; 1. Call the new library &quot;plot2&quot;, and make &quot;plot&quot; be a compatibility<br>&gt;&gt; layer for &quot;plot2&quot;. Add pointers in strategic locations of &quot;plot&quot; parts<br>&gt;&gt; of documentation, saying telling reader probably want to use &quot;plot2&quot; for<br>
&gt;&gt; new development.<br>&gt;<br>&gt; That&#39;s what Robby wants. I&#39;ve tried it that way as well. It works fine.<br>&gt;<br>&gt; My main problem with it is when *future* users search for &quot;plot&quot; in the documentation. They&#39;d get the pointers in strategic locations, yes, but users don&#39;t always read text. And the pointers would have to be in a lot of places.<br>
<br>Just to be clear I don&#39;t insist that it be that way forever. Only for a while so people have tine to port according to their schedules as opposed to ours. <br><br>That said, we definitely should still do a good job on the docs (explaining how to port and what is deprecated). I don&#39;t think that this is really all that bad; easier than what Neil T is contemplating below, I expect. :)<br>
<br>&gt;&gt; 2. Make the APIs for the old library and new library not conflict, by<br>&gt;&gt; making any necessary changes to the new API, and put both APIs together<br>&gt;&gt; in single library named &quot;plot&quot; that users get with &quot;(require plot)&quot;.<br>
&gt;&gt; Document the old API parts as deprecated.<br>&gt;<br>&gt; I had thought of this, but not seriously checked it out until you suggested it just now.<br>&gt;<br>&gt; The main incompatibility is how &quot;plot data&quot; is represented. In the old library, it&#39;s a function from a plot-view% (a descendant of image-snip%) to void. There&#39;s no way for something like that to communicate its bounds to &#39;plot&#39;. So in the new one, plot data is represented by a struct.<br>
&gt;<br>&gt; That difference is okay as long as nobody peeks at the plot data, just passing it off to &#39;plot&#39;, and combining them using &#39;mix&#39;. I assume most users have done that.<br>&gt;<br>&gt; There&#39;s wonkiness in the old API. The &#39;line&#39; function, for example, plots functions, parametric functions, polar functions, and parametric functions with a polar mapping. Sometimes some keywords matter, based on the values of other keywords. It&#39;s overloaded and messy.<br>
&gt;<br>&gt; The &#39;plot3d&#39; function has a keyword named &#39;#:az&#39;, for &quot;azimuth&quot;. No user needs to know that technical term. It&#39;s just the horizontal angle at which you view the plot. I called it &#39;#:angle&#39;.<br>
&gt;<br>&gt; The &#39;vector-field&#39; function has a &#39;#:style&#39; keyword that determines how the arrows are scaled. I use &#39;#:style&#39; for pen and brush styles (dashes, cross-hatching, etc.).<br>&gt;<br>&gt; There are quite a few little differences like that.<br>
&gt;<br>&gt; But there are enough similarities that I think I could do this option. I&#39;d still want to have a compatibility module, just in case. The documentation would be tricky. I&#39;d probably document only new, self-consistent functions and keywords, but have notes about extra keywords for compatibility, and a separate section on backward-compatible functions.<br>
&gt;<br>&gt; Hmm...<br>&gt;<br>&gt; Neil T<br>&gt; _________________________________________________<br>&gt;  For list-related administrative tasks:<br>&gt;  <a href="http://lists.racket-lang.org/listinfo/users">http://lists.racket-lang.org/listinfo/users</a><br>
&gt;