<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 11, 2013 at 8:40 PM, Asumu Takikawa <span dir="ltr">&lt;<a href="mailto:asumu@ccs.neu.edu" target="_blank">asumu@ccs.neu.edu</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 2013-01-11 20:35:50 -0600, Robby Findler wrote:<br>
&gt;    (The diff shows all of the tests changing). Are the tests for exported<br>
&gt;    functions? If so, that sound bad.<br>
<br>
</div>Only a subset of the string-&gt;date tests should have changed in the diff<br>
(which is how it shows up in my mail reader).<br>
<div class="im"><br></div></blockquote><div><br></div><div style>Oh, I see. These tests all appear to be about the item below we&#39;re debating (right?).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
&gt;    Was the mutation exposed via the library?<br>
<br>
</div>No, it wasn&#39;t.<br>
<div class="im"><br>
&gt;    That sounds like a backwards incompatible change (in that some programs<br>
&gt;    that could use srfi/19 would get #f out of selectors that now get<br>
&gt;    something else).<br>
&gt;    Could a srfi/19 date be a union of two structs, where one represented a<br>
&gt;    time only?<br>
<br>
</div>Potentially yes, but then it wouldn&#39;t be a Racket date struct. Also, I<br>
think the implementation of srfi/19 was actually violating its<br>
documented interface by allowing booleans to show up in these fields.<br><br></blockquote><div><br></div><div style>I think backwards compatibility here is probably more important than it producing a racket date. Is there some reason not to think so? I believe this library gets used a lot.</div>
<div style><br></div><div style>Maybe the parsing function could accept keyword optional arguments to say which day to use if one isn&#39;t specified? And if a date isn&#39;t specified, you&#39;d get back a srfi/19 time struct instead of a racket date struct in this case (but where the other srfi/19 accessors return &#39;#t&#39;s when they get time structs).</div>
<div style><br></div><div style>Robby </div></div><br></div></div>