Hi all,
I had a few design questions about date types as used in the racket/date
and srfi/19 libraries.
First, for some reason racket/date and srfi/19 use mutually incompatible
date representations and this is noted in the documentation (so it's
intentional). Is there a good reason for this? As
FWIW I did some sort of port of SRFI/19 to Typed Racket. I recall doing
something along the lines of bridging the impedance mismatch between Racket
and the SRFI, but whatever it was, was minimal. I was in a hurry. If
anyone is interested.
- date.rkt was a standard TR require/typed wrapping of
On Fri, Jan 11, 2013 at 7:04 PM, Asumu Takikawa as...@ccs.neu.edu wrote:
Note: in the long run, it's probably best to have a comprehensive
srfi/19 replacement in racket/date,
Agreed.
srfi/19 also has some serious flaws, which I have no time at the
moment to delve into.
The one merit it has,
On Jan 11, 2013, at 2:34 PM, John Clements wrote:
You may want to look instead at (the time related parts of) SOFA
(www.iausofa.org).
For my needs, I'm working at an FFI interface to SOFA, which I'll
release on planet when ready.
I much prefer pure racket code to FFI stuff--fewer
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.
And as you probably guessed, racket/date is the way it is for backwards
compatibility reasons. I
Second, the date structure used by racket/date has some seemingly
extraneous fields. For example, `week-day` and `year-day` can be
calculated from the rest of the fields and aren't necessary (this is
annoying if you want to construct your own dates manually).
I've been confused by this in the
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
On Fri, Jan 11, 2013 at 8:13 PM, Asumu Takikawa as...@ccs.neu.edu 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
On 2013-01-11 20:35:50 -0600, Robby Findler wrote:
(The diff shows all of the tests changing). Are the tests for exported
functions? If so, that sound bad.
Only a subset of the string-date tests should have changed in the diff
(which is how it shows up in my mail reader).
Was the
On Fri, Jan 11, 2013 at 8:40 PM, Asumu Takikawa as...@ccs.neu.edu wrote:
On 2013-01-11 20:35:50 -0600, Robby Findler wrote:
(The diff shows all of the tests changing). Are the tests for exported
functions? If so, that sound bad.
Only a subset of the string-date tests should have
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
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
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
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
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
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
16 matches
Mail list logo
