On Thu, Feb 17, 2011 at 9:37 PM, Johan Tibell
Edward,
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 functions?)
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 them. -Edward Kmett