Laziness and strictness are both important depending on the situation.
I'd recommend keeping both variants around. Having to wrap values in
an extra data type just to keep laziness sort of defeats the point of
Haskell being lazy in the first place. It also makes it somewhat
awkward to use in the cases where laziness is important, which is, I
suspect, quite a lot of the time where the codomain of the Map is a
recursive datatype.
Having lazy and strict variants of data structure libraries (i.e.
splitting the modules into *.Lazy and *.Strict) seems like a good idea
though, but I can imagine some cases arising where it would be
convenient to swap between the two, so it would be good to keep the
type the same anyway. The parent module would then reexport one of the
variants. (Obviously the lazy one, since this is Haskell, right? ;)
- Cale
On 29/12/05, Udo Stenzel
David Roundy wrote:
Should the Map modules have an additional Map.insertWith' that behaves strictly, or might it be the case that you always want strict behavior when using insertWith?
I think so. Once strictness is lost, there's nothing the user of a library could do about it. If a container is too strict however, lazyness can be recovered by wrapping values in an additional data type. So strict variants of updating functions would be a big win, and if two versions of every function are deemed too much of a burden, I'd rather get rid of the lazy version.
Udo. -- Ours is a world where people don't know what they want and are willing to go through hell to get it. -- Don Marquis
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDtAMdc1ZCC9bsOpURAs7ZAJ9pS/L7pf9tpRoTGi3HDR0gyindOQCfakED Xdpm15vvyqF51QAmCJeCm1U= =tZhs -----END PGP SIGNATURE-----
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries