Make it possible to evaluate monadic actions when assigningrecord fields

Iavor Diatchki iavor.diatchki at
Mon Jul 16 23:22:14 EDT 2007


I find the naming of values that is introduced by the "do" notation
useful and I am not at all convinced that the extra sugar that is
being proposed here makes the language simpler.  It seems to me that
the only way to know that a piece of code is safe would be to:
i) do the translation in your head to convince yourself that the
effects will be executed in the right order,
ii) make sure that you are using a commutative monad, or the order of
the effects is not important.

I like the current status quo because:
i) for values I can apply the usual pure reasoning that I am used to in Haskell,
ii) this makes it easier to refactor code, at least for me (e.g., it
is easy to insert a 'seq' here and there to control evaluation if I
have to)
iii) I find that it is easier to understand code that is a bit more
explicit because I have to keep less translations in my head
iv) I can use "fmap" and "ap" (and friends, e.g., like what Connor
suggested) to achieve a style that is similar to the imperative one,
when I think that the explicit naming is clumsy.

PS: Someone suggested that this syntactic sugar might be useful in the
context of STM or concurrent programming but I am skeptical about that
example because in that setting the order of effects is very
important... I could be convinced with examples though :-)

On 7/15/07, Chris Smith <cdsmith at> wrote:
> Hope you don't mind my butting in.
> If you're looking for a "compelling use case" to make programming with
> monads more natural in Haskell, I'd say STM makes for a good one.  There
> is no question there as to whether a monad is the right way to do STM;
> it is required.
> In working on some code recently that uses STM rather heavily, what I've
> found is that there are a couple things that make the experience
> somewhat painful despite the general promise of the technique.  The most
> important is fixed by Simon's proposal for monad splices.  I'd literally
> jump for joy if something like this were included in a future version of
> Haskell!
> Frankly, I don't think anyone will be convinced to use a more functional
> style by making programming in the STM monad more painful to do in
> Haskell.  Instead, they will be convinced to be more hesitant about
> using Haskell for concurrent programming.
> --
> Chris Smith
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at

More information about the Haskell-prime mailing list