[Haskell-cafe] strange stack overflow with Data.Map

[Cale Gibbard]

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 <u.stenzel at web.de> wrote:
> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
>