[Haskell-cafe] Re: monad subexpressions
cdsmith at twu.net
Fri Aug 3 12:09:49 EDT 2007
apfelmus <apfelmus at quantentunnel.de> wrote:
> 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
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
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".
More information about the Haskell-Cafe