Data.HashMap: Strict or lazy by default?
ekmett at gmail.com
Fri Feb 18 04:27:33 CET 2011
On Thu, Feb 17, 2011 at 9:37 PM, Johan Tibell <johan.tibell at gmail.com>wrote:
> Thanks for your thorough reply. Note that we can still have the actual
> data type be lazy in the values and thus have a Functor instance etc.
> Strictness can be added at the level of functions. Knowing that we can
> have all the lazy goodies the question is: what should be the default
> API in terms of strictness and what should the module layout look like
> (e.g. where should we put the lazy and strict insert insertWith
I'm relieved to hear you say that. =) Without seeing the code, without the
(!) annotations, while you'll get the same control over space leaks, the
strictness analyzer won't really derive any knowledge about the
evaluatedness of a retrieved value, so the emitted code may differ slightly,
but I doubt it'd be a measurable difference.
I'd vote for Data.HashMap.Lazy and Data.HashMap.Strict with Data.HashMap
just re-exporting Data.HashMap.Lazy. That way someone can just swap imports
from Data.Map to Data.HashMap and not be surprised by strictness changes and
it mirrors the behavior of mtl/transformers and similar libraries (even my
comonad-transformers ;) ).
Since there is no structural difference, and the instances could be shared
you could get away with a single common data type that you export through
both modules. This would break a bit from the traditions of these other
packages, but it'd let users sprinkle a little strictness (or conversely,
laziness) through their code as needed with qualified Strict.map,
Strict.insertWith, etc's or change imports to swap wholesale. The price is
they couldn't build separate instances for strict vs. lazy Data.Hashmaps,
the benefit is that they don't _have_ to build separate instances for strict
vs. lazy Data.Hashmaps, and that they could mix and match methods between
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries