Hello,
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.
-Iavor
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
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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime