[Haskell-cafe] a regressive view of support for imperative programming in Haskell

[David Roundy]

On Wed, Aug 08, 2007 at 02:20:39PM -0400, Paul Hudak wrote:
> All of the recent talk of support for imperative programming in Haskell 
> makes me really nervous.  To be honest, I've always been a bit 
> uncomfortable even with monad syntax.  Instead of:
> 
> do x <- cmd1
>     y <- cmd2
>     ...
>     return e
> 
> I was always perfectly happy with:
> 
> cmd1 >>= \x->
> cmd2 >>= \y->
> ...
> return e

I may be stating the obvious here, but I strongly prefer the do syntax.
It's nice to know the other also, but the combination of do+indenting makes
complicated code much clearer than the nested parentheses that would be
required with purely >>= syntax.

> Well, you could argue, monad syntax is what really made Haskell become 
> more accepted by the masses, and you may be right (although perhaps 
> Simon's extraordinary performance at OSCOM is more of what we need).  On 
> the other hand, if we give imperative programmers the tools to do all 
> the things they are used to doing in C++, then we will be depriving them 
> of the joys of programming in the Functional Way.  How many times have 
> we seen responses to newbie posts along the lines of, "That's how you'd 
> do it in C++, but in Haskell here's a better way...".

(I suppose I just did as you suggested I could...)

I'd say that monadic programming is *not* the same as C++ programming.
"Normal" programming in a Haskell monad (e.g. parsing, Maybe, IO) does not
involve IORefs, and generally behaves quite nicely.

Several times since reading the beginning of this discussion I've wished I
had the new syntax so I could write something like:

  do if predicateOnFileContents (<- readFile "foo") then ...

instead of either

  do contents <- readFile "foo"
     if predicateOnFileContents contents then ...

or (as you'd prefer)

  readFile "foo" >>= \contents ->
  if predicateOnFileContents contents then ...

As long as the sugar has a pretty obvious desugaring (which I seem to
recall it did), I don't see how it's likely to make things worse.  And
there are an awful lot of situations where code would be reduced by a line,
and (much more importantly) by a temporary variable.  Every temporary
variable declared adds that much syntactic overhead to a function, since
the reader is forced to scan through the rest of the function to see if it
is ever used again before he can understand what is being done and how it's
being used.
-- 
David Roundy
Department of Physics
Oregon State University