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 <as...@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 >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
