Re: Strictness of modify in Control.Monad.State.Strict
Ben Gamari <bgamari.foss <at> gmail.com>
2012-10-12 17:52:48 GMT
Edward Kmett <ekmett <at> gmail.com> writes:
> The strictness of Control.Monad.State.Strict has to do with the strictness
> of the tuple constructor, not of the state per se. The dichotomy between
> Lazy and Strict comes from the competing desires to fake products as
> categorical products that don't introduce _|_'s of their own and the lifted
> products we have in Haskell which do. The former leads you to the .Lazy
> model, the latter leads you to the .Strict model. The former is nicer for
> certain lazy knot tying tricks. The latter is easier to reason about when
> you start throwing fmap _|_'s around.
> However, a Strict State or Writer is not actually strict in the state or
> log. This is admittedly a somewhat common misconception.
> My concern is that such a combinator would exacerbate this confusion and
> that it doesn't generalize. e.g. This trick doesn't generalize to
> Strict.Writer, where you can `tell'`, but then you lose than on the next
> bind after you lazily smash it into something that is probably just mempty.
I understand your concern regarding the inability to generalize to
Writer. That being said, does it do any harm to include a truly strict
combinator in Strict.State?
I for one end up rewriting modify' fairly often (or when I don't, I
generally only realize after the first stack overflow). As I mentioned
earlier, I think just the presence of "modify'" in the documentation
would lead many new Haskellers to catch their mistake before even facing
the dreaded "*** Exception: stack overflow".
Regardless, it seems there is a general consensus around improving the
treatment of laziness in the documentation. Unfortunately, not having
mastered this myself, I'm not sure I'd be a terribly good candidate to
write this language. Any volunteers?