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 <[EMAIL PROTECTED]> 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
