Re: A View of Monads (Re: performance of monads)

"Eray Ozkural (exa)" wrote:

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

Right. When you need an explicitly ordered thread of control, you use a monad to `drive' that thread. The rest of the program can be expressed in purely functional terms.

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.

Naturally, that's a danger. Anything can be used to excess. The old saying goes `you can write FORTRAN in any language. The point is to use monads to `abstract out' the imperativeness. One way to think of it is to look at a program as a partially ordered set of calculations; some calculations need to occur before others, other groups can occur in any order. In an imperative language you specify a total ordering (which is overkill). In a pure functional language (without monads) the only order you can supply is through function application (and the evaluation model -- possible, but syntactically unwieldly. Monads merely provide a syntactical convenience.

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.

Actually not; the monad itself _is_ the interface. In the absence of side-effects, you do not need to be concerned with synchronization, for example. Values are generated when needed.

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. :)

Indeed, some problems are best solved by imperative means. Some algorithms cannot be expressed in a purely functional framework as efficiently as in a side-effecting one. Still, the ability to easily reason about code (or prove the correctness of code) is quite compelling. One must choose the tool appropriate for the task. Of course, not being an expert (nor really playing one on the mailing list), YMMV.

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

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Cheers, --ag -- Artie Gold -- Austin, TX agold@bga.com "May you keep turning the pages. And may the book never end."