[Haskell-cafe] Re: monad subexpressions

[Chris Smith]

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 
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