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 <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