A View of Monads (Re: performance of monads)

[Artie Gold]

"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) <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-----
> 
> _______________________________________________
> 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."