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

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.

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. And if we keep pushing a little more, then we can
probably get all of the extra functionality of srfi/19 into racket/date and
declare srfi/19 to be used only in old code and freeze it completely.

Robby



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

> On 2013-01-11 20:58:02 -0600, Robby Findler wrote:
> >    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.
>
> Ok, attached is a second attempt that will use a different struct type
> if `string->date` gets passed a format string that's missing day, month,
> or year. The `make-date` function will also construct one of these lax
> types if the day, month, or year fields is #t.  These dates should work
> normally, except that racket/date won't like them.
>
> This doesn't attempt to preserve other laxness in srfi/19. For example,
> `make-date` previously would not do any error checking of its fields (so
> it won't error until an operation is used which cares about that field).
>
> It should also support deserialization like Ryan pointed out.
>
> Cheers,
> Asumu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130111/ec61a6e3/attachment.html>