memory useage of data types in the time package

[Yitzchak Gale]

Duncan Coutts wrote:
> There are various sorts of programs that deal with a large quantity of
> data and often that includes some date/time data. It's a great shame
> that programs dealing with lots of time data might have to avoid using
> the time package and revert to things like
> newtype Seconds = Seconds Int32
> simply because they take less space, and can be unpacked into other data
> structures.

That is true. But on the other hand, my guess is that most applications
don't need those optimizations.

One of the most common complaints heard about Haskell is that Data.Time
is so much more difficult to use than the basic time API in most other
languages. I believe that those complaints are totally unjustified. It's
more difficult because unlike the others, it is correct, and it uses the
type system to prevent subtle intermittant bugs that almost always
exist in applications using those other libraries. But in any case,
I think we should be very careful not to make the interface even
more complicated just to achieve what is a premature optimization
in the vast majority of applications.

Many of the suggestions you are making would actually be transparent
except when constructors are used explicitly. So perhaps we could
achieve most of what you are suggesting without changing the interface
if we provide polymorphic functions in place of each of the constructors,
then move the actual contructors to "Internals" modules for use only
by those who need them. We would then be free to change the internal
types now and in the future without significant impact on the interface.

As for laziness, it's usually not correct to have strictness by default
in a library as general as this one. For example, it's conceivable that
someone will construct a UTCTime where the Day is easy to compute
but the TimeOfDay results in heavy computation or even a bottom.
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.

Perhaps we could introduce strict alternatives for some of the functions.
That wouldn't help the size of the data types though, unless we change
some of them to type classes...

Regards,
Yitz