[Haskell] Mixing monadic and non-monadic functions

[Ben Rudiak-Gould]

On Tue, 23 Mar 2004, Sean E. Russell wrote:

> The standard explaination about why monads are so troublesome always sounds 
> like an excuse to me.  We have monads, because they allow side-effects.  Ok.  
> If programs that used side effects were uncommon, I'd be fine with them being 
> troublesome -- but they aren't.  Maybe it is just me, but my Haskell programs 
> invariably develop a need for side effects within a few tens of lines of 
> code, whether IO, Maybe, or whatnot.  And I can't help but think that 
> language support to make dealing with monads easier -- that is, to integrate 
> monads with the rest of the language, so as to alleviate the need for 
> constant lifting -- would be a Good Thing.

I agree with this, but the support you describe is difficult to add.

Programming languages differ not so much in what they make possible as in
what they make easy. In Haskell (to pick just a few examples):

  * Memory management (allocation and deallocation) is effortless.

  * Creating lexical closures is very easy.

  * You don't have to declare the types of all your functions and local
    bindings, because the implementation can figure them out for itself.

  * You don't have to ensure that values are computed before they're used,
    because the implementation handles that too.

If you were learning C instead of Haskell, you'd be complaining (and
rightly so) about the effort required to do these things in C.

Unfortunately, no one has figured out how to make everything easy at the
same time, and the problem you've run into is an example of this. The
monad I/O model exists because of implicit data dependencies (the last
bullet point above); the "heavy lifting" exists because of type inference.
We'd all love to make the lifting implicit, but no one knows how to do it
without breaking the whole language.

A related problem which was discussed here recently is Haskell's lack of
per-type namespaces, something which even C programmers take for granted.
Again, the problem is the tricky interaction with type inference.

Unless/until these problems are resolved, all you can do is learn a bunch
of different languages and use the one which is most convenient for a
particular task. Haskell, for all its problems, is a strong contender for
many tasks.


-- Ben