memory useage of data types in the time package
wren ng thornton
wren at community.haskell.org
Sun May 23 06:42:47 EDT 2010
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
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
> 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.
More information about the Libraries