[racket-dev] racket/date, SRFI-19, date construction

On Fri, Jan 11, 2013 at 11:29 PM, Asumu Takikawa <asumu at ccs.neu.edu> wrote:

> On 2013-01-11 23:08:30 -0600, Robby Findler wrote:
> >    How about calling the new struct "lax-date" or something like that,
> using
> >    the word you're using below -- I'm not tied to that word, but
> something
> >    that explains more why it is there seems good.
>
> That sounds good.
>
> >    Also, I think the documentation needs to be updated to explain the
> >    relationship between the racket/date structs and the srfi-19 date
> structs.
> >    I'm less clear about the other laxness. One other possible thing to
> >    consider is that srfi:make-date could do all the same checking that
> date*
> >    does, but if any of it fails (perhaps catch the exn) it creates a lax
> >    date. That seems safest.
>
> I thought about this, and the only objection that I had was that a
> contract error could now silently turn into a valid old srfi/19 style
> date object. Then again, this would only happen with the constructor
> exported from srfi/19, so maybe it's not a big deal.
>
>
yes, I think this is the right reasoning -- it isn't a big deal that
srfi/19's constructor accepts everything (since it always has), but it is a
big deal to preserve backwards compatibility.


> In any case, see attached patch for implementation (just catches the
> exception).
>
>
>
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's important); that and the docs and I think it is ready
to commit.

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).

Thanks for taking this on!

Robby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130111/9e233b9f/attachment.html>