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