I can honestly say that I haven't felt much pain from the status quo regarding this. Most of the time my code is structured so that case statements don't appear in do blocks. When they do, I don't see it as a big issue. The special case for operator - is a bigger wart on haskell syntax than this, imo. I would vote in favor of keeping the language simple. I do like the idea of generalizing lambda functions to include multiple cases, however. On the other hand, I almost never use lambdas now since named functions yield better "self-documenting" code. --jonathan On Oct 8, 2010 8:09 AM, "Peter Wortmann" <scpmw@leeds.ac.uk> wrote: On Fri, 2010-10-08 at 01:13 +0300, Lauri Alanko wrote:

Your "general" rule doesn't subsume your ... Yes, that's what I meant. Thanks for describing it properly.

On Fri, 2010-10-08 at 05:41 -0700, Nicolas Pouillard wrote:

Imagine find this code:

do s1 ... This is roughly what I meant with "abused": Where "C" is very complex, it might become non-obvious where exactly the monad actions are supposed to happen. Hence such traps when refactoring.

Also of note: Just moving sub-expressions around isn't something that is guaranteed to be save. Introducing new names and using them in "s2" would be problematic, for example: do map (\x -> (<- putStrLn x)) ["a", "b"] Obviously can't be made to work. You might have to check for this - or maybe even disallow the shorthand inside lamdbas and lets. Might be less satisfying to have such special cases, but it is still a good bit more general than what is available right now. Greetings, Peter Wortmann _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org...