On Fri, Jan 11, 2013 at 11:29 PM, Asumu Takikawa 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 mor
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 t
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 s
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 differen
Oh! Good point!
On Fri, Jan 11, 2013 at 9:53 PM, Ryan Culpepper 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
> fun
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
On Fri, Jan 11, 2013 at 8:40 PM, Asumu Takikawa 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 changed in the
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: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 examp
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 thes
On Fri, Jan 11, 2013 at 4:39 PM, Robby Findler
wrote:
>
> And as you probably guessed, racket/date is the way it is for backwards
> compatibility reasons. I don't know how srfi/19 came to be, but it might
> just be because someone took the sample implementation from the srfi and
> stuck it into R
> 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
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 don't
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
On Jan 11, 2013, at 10:53 AM, Pierpaolo Bernardi wrote:
> On Fri, Jan 11, 2013 at 7:04 PM, Asumu Takikawa 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 t
On Fri, Jan 11, 2013 at 7:04 PM, Asumu Takikawa 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, is that being an
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 s
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 f
18 matches
Mail list logo
