[Haskell-cafe] [Haskell] ANNOUNCE: time-recurrence-0.1

[Chris Heller]

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