Strictness of modify in Control.Monad.State.Strict

[Ben Gamari]

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?

Cheers,

- Ben