On Fri, Jan 11, 2013 at 11:29 PM, Asumu Takikawa <as...@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
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
