Oh! Good point!
On Fri, Jan 11, 2013 at 9:53 PM, Ryan Culpepper <ry...@ccs.neu.edu> wrote: > I don't know how important this is, but ideally serialized old SRFI-19 > dates should now deserialize as date*. I think that you can just restore > the definition of deserialize-info:tm:date-v0 and change the second > function (the cyclic value builder) to raise an error: > > (define deserialize-info:tm:date-v0 > (make-deserialize-info > srfi:make-date > (lambda () > (error 'deserialize-info:tm:date-v0 "cycles not allowed")))) > > and also restore the provide. > > Ryan > > > > On 01/11/2013 09:13 PM, Asumu Takikawa wrote: > >> On 2013-01-11 15:39:08 -0600, Robby Findler wrote: >> >>> I think it would be great if you were to find backwards-compatible >>> ways to bring these two a little bit closer. Making them use the >>> same internal date struct, for example, would be a great thing. >>> >> >> I wrote a patch to make both of these use the same structure, attached >> to the e-mail. It seems to pass all of the srfi-19 and date tests (with >> some tests changed where appropriate). Does it look alright? >> >> It turns out there was one (sort of) good reason for SRFI-19 to define >> its own struct type: it used mutation for several functions. Racket's >> date/date* are immutable. I just changed these to use functional update. >> >> Another thing: when a string is converted to a date, it's possible that >> the format string only has time-of-day but no date specification. >> Previously, this produced a srfi/19 date with '#t's but I've now >> defaulted it to the start day of the Unix epoch (arbitrarily). >> >> Cheers, >> Asumu >> >> >> >> _________________________ >> Racket Developers list: >> http://lists.racket-lang.org/**dev <http://lists.racket-lang.org/dev> >> >> > _________________________ > Racket Developers list: > http://lists.racket-lang.org/**dev <http://lists.racket-lang.org/dev> >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev