<div dir="ltr">On Fri, Jan 11, 2013 at 11:29 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><div class="gmail_extra"><div class="gmail_quote">
<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 23:08:30 -0600, Robby Findler wrote:<br>
&gt;    How about calling the new struct &quot;lax-date&quot; or something like that, using<br>
&gt;    the word you&#39;re using below -- I&#39;m not tied to that word, but something<br>
&gt;    that explains more why it is there seems good.<br>
<br>
</div>That sounds good.<br>
<div class="im"><br>
&gt;    Also, I think the documentation needs to be updated to explain the<br>
&gt;    relationship between the racket/date structs and the srfi-19 date structs.<br>
&gt;    I&#39;m less clear about the other laxness. One other possible thing to<br>
&gt;    consider is that srfi:make-date could do all the same checking that date*<br>
&gt;    does, but if any of it fails (perhaps catch the exn) it creates a lax<br>
&gt;    date. That seems safest.<br>
<br>
</div>I thought about this, and the only objection that I had was that a<br>
contract error could now silently turn into a valid old srfi/19 style<br>
date object. Then again, this would only happen with the constructor<br>
exported from srfi/19, so maybe it&#39;s not a big deal.<br>
<br></blockquote><div><br></div><div style>yes, I think this is the right reasoning -- it isn&#39;t a big deal that srfi/19&#39;s constructor accepts everything (since it always has), but it is a big deal to preserve backwards compatibility.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In any case, see attached patch for implementation (just catches the<br>
exception).<br>
<br><br></blockquote><div><br></div><div style>I think it needs a few more test cases to test for the new racket/date functionality (ie that some calls return racket/date dates) and I think it makes sense to export the lax-date? predicate (perhaps from another library if you think that&#39;s important); that and the docs and I think it is ready to commit.</div>
<div style><br></div><div style>Also, are there test cases that test the #t behavior for parsing time-only strings? If not, probably good to add those (and make sure those tests pass in the old version).</div><div style><br>
</div><div style>Thanks for taking this on!</div><div style><br></div><div style>Robby</div></div><br></div></div>