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 RD.
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 g...@sefer.org wrote:
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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
