apfelmus
I still think that this syntax extension has profound impact and is a bad idea. Simon's and Neill's use case was the dreaded name-supply monad where the order of effects really doesn't matter up to alpha-conversion. The objection to that use case is that monads are not the right abstraction for that, they're too general.
I'm primarily interested in the two cases where one simply has no choice about the use of monads: and those are IO and STM. No, this is not purely functional programming then; but it has some very compelling advantages to Haskell's implementation of these, that I'm afraid are currently quite hidden behind the difficult syntax. Using something besides a monad is simply not an option. A lot of what I'm thinking about Haskell now comes from my experience in trying to teach it to new programmers (which in turn comes from it being lonenly to be the only person I talk to that knows Haskell). I'm quite convinced, right now, that one huge problem with adoption of Haskell has to do with this right here. If there's a way to get nice syntax without modifying the compiler, that is certainly an advantage; but I do see it as rather small compared to the goal of producing something that it rather simple to understand and use. I can explain desugaring rules for this idea in a short paragraph. The alternatives all seem to involve operators and functions that I've not used in about six months or more of moderate playing around with Haskell. Type class hacking is way over the top; other ideas seem reasonable to me, but I'm concerned they won't seem very reasonable to anyone with much less experience using Haskell than I've got. The other objection, though, and I'm quoting from a post in a past thread on this, is something like, "The more tiresome monads are, the more incentive you have to avoid them." Unfortunately, I'm afraid this cheapens work people are doing in making the necessary imperative parts of Haskell more useful and interesting. Making monads distasteful is not a reasonable goal.
Also, I got so frustrated that I ended up abandoning some code recently because STM is, in the end, so darn hard to use as a result of this issue. I'd love to see this solved, and I'm quite eager to do it.
This sounds suspicious, since the order of effects is of course important in the STM monad. Can you post an example of code you intend to abandon due to ugliness? I'd be astonished if there's no better way to write it.
I'll dig for it later if you like. The essence of the matter was a bunch of functions that looked something like this: foo = do b' <- readTVar b c' <- readTVar c d' <- readTvar d return (b' + c' / d') In other words, a string of readTVar statements, followed by one computation on the results. Each variable name has to be duplicated before it can be used, and the function is four lines long instead of one. It's true that order of effects *can* be important in monads like IO and STM. It's also true, though, that probably 50% of the time with IO, and 95% with STM, the order does not actually matter. Taking a hard-line approach on this and forcing a linear code structure is equivalent to ignoring what experience has taught in dozens of other programming languages. Can you think of a single widely used programming language that forces programmers to write linear one-line-per-operation code like this? IMO, Haskell gets away with this because STM and IO stuff isn't very common; and STM and IO will remain uncommon (and will instead be replaced by unsafe code written in Python or Ruby) as long as this is the case. I find it hard to speculate that Haskell programmers will understand the alternatives, but won't understand something like "monadic subexpressions are evaluated in the order of their closing parentheses". -- Chris Smith