A View of Monads (Re: performance of monads)
Eray Ozkural (exa)
Wed, 16 Jan 2002 20:47:28 +0200
-----BEGIN PGP SIGNED MESSAGE-----
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
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. :)
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.
Eray Ozkural (exa) <email@example.com>
Comp. Sci. Dept., Bilkent University, Ankara
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
-----END PGP SIGNATURE-----