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