
Duncan Coutts wrote:
Yitzchak Gale wrote:
That user would be unpleasantly surprised if we introduced strictness. Gratuitous strictness is also a premature optimization, especially in a general-purpose library. Haskell is lazy by default.
It's not a hard and fast rule that everything should be lazy. I certainly appreciate that we need lazyness in the right places. I think it depends on whether we consider these values as units or not.
I tend to think of time values as atomic units, like complex or rational numbers. The standard H98 complex and rational types are strict in their components, because conceptually they're not compound types, they're atomic.
I agree. While I haven't used this library (I've had no reason to yet), when dealing with times in other languages, my default conception is to treat them like atomic units and I see no reason to think of them differently in Haskell. While laziness by default is nice, too much laziness is just as bad as too much strictness. I can't really imagine a use for laziness in calculating the components of a time record. Even if there are some cases where it'd be desirable, they seem rare enough that they could be supported by a separate module that provides lazy variants of the default implementation (just as other libraries offer both strict and lazy variants). It'd be nice not to have to complicate the API, but I don't see a good argument for not having the default library use strict unboxed records.
Perhaps we can see what other people think about the balance of use cases between those that need the lazyness vs those that need compat representations. I may well be overestimating how common the latter use case is.
I don't think the *need* for compact representations is terribly common, but this strikes me as the sort of optimizations we should expect from base libraries. When the need does arise, it's much better to be pleasantly surprised that things just work, rather than lamenting the fact that Haskell isn't ready for prime time. Because it's a base library and is intended to be the primary library for time, this doesn't strike me as premature in the slightest. -- Live well, ~wren