Re: [Haskell-cafe] [Haskell] ANNOUNCE: time-recurrence-0.1
Moving the discussion from haskell to haskell-cafe. Chris Heller wrote:
http://github.com/hellertime/time-recurrence A library for generating and inspecting recurring times.
Very nice. Please put it up on hackage so we can see the haddocks, try it out easily, etc.
hoping to solicit some feedback on its design.
Very well done. I have been think about recurrence rules, too. Version 2 Olson timezone files contain POSIX rules to specify clock change rules for times later than the last one listed in the timezone series. Currently, the timezone-series package ignores those. I like your introduction of symbolic months and weekdays. The numeric-only interface of Data.Time for those things leads to messiness like multiple functions depending on how you number the weekdays. That logic should be moved out to a separate interface. You are correct that it is worth creating a separate module for that. Please do so! Include neater versions of the corresponding functions from Data.Time. Another comment - I would have used fromGregorianValid instead of fromGregorian. It's not a good idea for a basic time library to introduce possible crashes. At least you should provide an alternative safe interface. Similarly for toEnum.
The general direction is to have something that works much like the RRULE portion of the iCalendar (RFC 5545) specification. I have decided avoid strict RFC compliance at this time.
Ashley Yakeley wrote:
At one point I investigated a really generalised version of this, including an abstract syntax type and perhaps a way of parsing some useful subset of English expressions into it. However I got stuck on such things as
"any day after the sixth Sunday of a month"
In order to prove that today was not such a day, it would have know that "sixth Sunday of a month" never happens. Simply searching into the past for one would never terminate. Either I would have to restrict the language, or assert the beginning of time (not necessarily a bad solution).
I don't see why you would need to make any such restrictions. There would only be a finite number of primitive comparison types, and since your language would be total, any expression could be reduced to the primitive ones in a finite number of steps. Then it would just be a matter of arithmetic on sets of ranges; see, for example, http://hackage.haskell.org/package/Ranged-sets That allows for half-infinite and infinite ranges as well. Regards, Yitz
Thanks for the feed back.
Very nice. Please put it up on hackage so we can see the haddocks, try it out easily, etc.
I've registered for an account, and will have it up on Hackage just as soon as I can. For now you can see the Haddock docs for the library at: http://hellertime.github.com/time-recurrence
You are correct that it is worth creating a separate module for that. Please do so! Include neater versions of the corresponding functions from Data.Time.
I'll investigate what it will take to improve things in this regard. Ashley, your input would obviously be appreciated in this matter.
provide an alternative safe interface. Similarly for toEnum
Yitz, are you suggesting something like doing modulo arithmetic rather than calling error on undefined values?
At one point I investigated a really generalised version of this, including an abstract syntax type and perhaps a way of parsing some useful subset of English expressions into it
Ashley, this sounds quite ambitious and certainly would be an
interesting project to work on. I think the scope of this current
project is much smaller, but perhaps might be a useful building block
or more likely just some simple R&D.
Regarding the current time-recurrence library, I've started looking
into combining the filter operations (byMonth, byYearDay,
byWeekNumber, etc...) to build a single function that can enumerate
the dates in the recurrence.
I may be interesting to see how things would work if instead of
creating an enumerating function I created a RangedSet.
-Chris
On Mon, May 23, 2011 at 2:35 AM, Yitzchak Gale
Moving the discussion from haskell to haskell-cafe.
Chris Heller wrote:
http://github.com/hellertime/time-recurrence A library for generating and inspecting recurring times.
Very nice. Please put it up on hackage so we can see the haddocks, try it out easily, etc.
hoping to solicit some feedback on its design.
Very well done.
I have been think about recurrence rules, too. Version 2 Olson timezone files contain POSIX rules to specify clock change rules for times later than the last one listed in the timezone series. Currently, the timezone-series package ignores those.
I like your introduction of symbolic months and weekdays. The numeric-only interface of Data.Time for those things leads to messiness like multiple functions depending on how you number the weekdays. That logic should be moved out to a separate interface.
You are correct that it is worth creating a separate module for that. Please do so! Include neater versions of the corresponding functions from Data.Time.
Another comment - I would have used fromGregorianValid instead of fromGregorian. It's not a good idea for a basic time library to introduce possible crashes. At least you should provide an alternative safe interface. Similarly for toEnum.
The general direction is to have something that works much like the RRULE portion of the iCalendar (RFC 5545) specification. I have decided avoid strict RFC compliance at this time.
Ashley Yakeley wrote:
At one point I investigated a really generalised version of this, including an abstract syntax type and perhaps a way of parsing some useful subset of English expressions into it. However I got stuck on such things as
"any day after the sixth Sunday of a month"
In order to prove that today was not such a day, it would have know that "sixth Sunday of a month" never happens. Simply searching into the past for one would never terminate. Either I would have to restrict the language, or assert the beginning of time (not necessarily a bad solution).
I don't see why you would need to make any such restrictions.
There would only be a finite number of primitive comparison types, and since your language would be total, any expression could be reduced to the primitive ones in a finite number of steps. Then it would just be a matter of arithmetic on sets of ranges; see, for example, http://hackage.haskell.org/package/Ranged-sets That allows for half-infinite and infinite ranges as well.
Regards, Yitz
I wrote:
It's not a good idea for a basic time library to introduce possible crashes. At least you should provide an alternative safe interface. Similarly for toEnum.
Chris Heller wrote:
are you suggesting something like doing modulo arithmetic rather than calling error on undefined values?
Well, the standard "safe interface" would just wrap the return type in Maybe, like fromGregorianValid does. Then you might use it something like this: maybe [] (map moment . take 5 . recurBy 10 [] . Daily) maybeStartDate Using modulo arithmetic for toEnum would indeed make the function safe, but I'm not sure that would give the results that users are expecting. For the start date of a recurrence, though, you are right that you might be able to do better than just using Maybe. Suppose you had a function that rounds an invalid Gregorian date forward to the nearest valid date. Then a user that asks for a recurrence starting with, say, Feb. 30 would get dates starting at the beginning of March, which is probably what was intended. Regards, Yitz
participants (2)
-
Chris Heller -
Yitzchak Gale