memory useage of data types in the time package

[wren ng thornton]

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