gale at sefer.org
Mon Jun 27 10:15:28 CEST 2011
Tony Morris wrote:
> I recently set out to write a library that required a decent time
> library. Having only had a flirt with Data.Time previously, I assumed
> it would be robust like many other haskell libraries. I don't know
> about consensus, but I have been massively let down. I won't go in to
> the details...
Data.Time is in some ways like Haskell itself. Though at first glance
it seems a little daunting, in reality its semantic correctness
makes it easier to use, not harder, than any of its alternatives
in any language that I know (and I am proficient in quite a few).
Once you have caught on, it is difficult to settle for anything less.
The biggest shortcoming, in my opinion, is that the documentation
assumes that the reader is very familiar with the Haskell type
system, and with viewing type signatures and instance lists as an
integral and central part of the documentation.
In particular, Haskell's standard numeric type classes and the
conversion functions between them play a central role in the API
of Data.Time. But you wouldn't realize that unless you have read
the type signatures and instance lists in the Haddocks very
carefully, and have thought about it for a while.
Another problem, as Malcolm pointed out, is that because of the
sheer size of the library, a quick-start guide for the common
cases would be extremely helpful for newcomers.
What other issues have you noticed?
> is there a reasonable alternative to Data.Time
> If I am right, and there is no alternative, I see no option but to
> take an excursion into writing my own.
No. There are several alternatives, but I have never seen anything
that has come close to Data.Time.
Before you undertake writing a whole new time library, why not
try writing some improved documentation for Data.Time first?
I think that would give the most immediate benefit to the
community, and I'm sure it would improve the quality of whatever
library of your own you end up writing.
More information about the Haskell-Cafe