[Haskell-cafe] State monad strictness - how?

[Josef Svenningsson]

Yitzchak,

I agree with you that both lazy and strict monads are important and
that we should have both options in a monad library.

But the fun doesn't end there. There are other strictness properties
to consider. Take the state monad for example. Should it be strict or
lazy in the state that it carries around? What about the value
component? I think the answer to these questions are the same as for
monadic strictness above: both strict and lazy variants are useful.

Now, the challenge here is to design a library which doesn't explode
in size from all the various possibilities for strictness or laziness.
In fact I did once bite the bullet and came up with a library that
does all this. Though I haven't released it publicly yet. I never took
the time to polish the code to the point where I wouldn't be
embarrassed about showing it to others.

If you kick me hard enough I might release the library.

Cheers,

Josef

On 1/10/07, Yitzchak Gale <gale at sefer.org> wrote:
> Hi Bulat,
>
> I wrote:
> >> [State and StateT] should be consistent. I
> >> would much prefer for them both to be lazy.
>
> Bulat Ziganshin wrote:
> > imho, lazy monads (as any other lazy things) is a source of beginner's
> > confusion. therefore it may be better to provide "default" monads as strict
> > and lazy ones - for one who knows what he wants - with a Lazy prefix, e.g.
> > LazyST, LazyState...
>
> Well, as long as both are provided, that is fine with me.
>
> But I do not think that laziness in monad methods is a reason
> for beginners' confusion.
>
> First of all, it is natural to get a little confused about strictness
> at the beginning. I'm not sure it happens more often with
> monads than anywhere else.
>
> If there is more confusion about strictness with monads,
> it is because of the fact that many introductions/tutorials
> confuse all monads with IO. They say something like:
>
> "So how do you create side effects in the real world? That is
> what monads are for."
>
> No, no, no! That is what ** IO ** is for. Most monads are pure!
>
> In fact, I think making the default strict will create more confusion.
>
> We should help beginners to understand right from the start that
> do-notation is not a "procedure" of commands for the computer
> to carry out. It is just a special syntax for defining functions. We
> use it when it is more natural to describe the effect of a function
> in a step-by-step style, just as happens sometimes in mathematics.
> But the compiler is under no obligation to follow our steps literally.
>
> Except with IO - when dealing with the real world, we need
> to be able to specify the exact order in which things happen.
>
> ST represents using physical memory as a fast storage device.
> So it is really IO in disguise.
>
> Regards,
> Yitz
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>