A View of Monads (Re: performance of monads)

Eray Ozkural (exa) erayo@cs.bilkent.edu.tr
Wed, 16 Jan 2002 20:47:28 +0200


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Let me offer a differing view of Monads.

Monads are a way to write type-safe imperative programs within a functional 
framework. It's just an advanced version of PROGN kludge in LISP.

Since they are based on a linear flow of "commands", they seem to necessitate 
sequential programming. Because of this reason I prefer not to use any monads 
whenever possible. It seems to eliminate the gist of functional programming.

OTOH, the nice thing about Monads is that they, I think, lift the semantics 
of an imperative language, to the language level. When I look at the analysis 
of Algol-like languages in Tennent's "Semantics of Programming Languages" 
book I see the same thing as Monads: a way to sequence commands, and pipe the 
effects.

Because of these reasons, I think the use of Monads are highly exaggerated. 
They are sort of like the over-use of "template" code in C++. In my 
experience, it doesn't work too well. You will end up writing monadic 
versions of everything, etc.

Of course, they are a nice way to abstact I/O. How else could you do it 
properly in a functional language? Monads effectively model the operation of 
a sequential machine (one I/O channel!) in a mathematical way.

It's similar to the problem of trying to retrofit a parallel system in a 
sequential system. Consider a sequential input source, and a parallel 
algorithm to compute it. You will need an interface between the two.

In that respect, whenever I use monads, I feel like going back to an 
imperative language because it will make my program much less concurrent. 
Wasn't the most important benefit of using a functional PL architecture 
independence? I think it has turned to "ease of programming" now, which isn't 
any more real. :)

Thanks,

On Wednesday 16 January 2002 17:05, you wrote:
> > I see a lot of literature that says that monads "simulate" the effects of
> > imperative programming concepts.
>
> I think that's just bad wording.  To take a rather trite
> point of view, in a language such as C /everything/ is done
> within a monad, and all types, even int, are really IO
> something (IO Int).
>
> In Haskell you may see costs associated with using Monads,
> but they are mainly to do with dealing with the difficulties
> that arise from having laziness everywhere.
>
>   Jón

- -- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8RcrAfAeuFodNU5wRAtSkAJ9dbVF4q33hCcwXedHDYA4MlAYv0wCeNb5p
shGjRg01VUmiGYTkW1LlmvM=
=mJDL
-----END PGP SIGNATURE-----