A View of Monads (Re: performance of monads)

[Adrian Hey]

On Monday 21 January 2002 17:34, you wrote:
> At 12:47 PM -0600 1/16/02, Eray Ozkural (exa) wrote:
> >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.
>
> That seems a bit too strong.
>
> If you'll have a look at Hutton and Meijer's monadic parsing library
> (ParseLib.hs, which is distributed with Hugs and described in
> http://www.cs.nott.ac.uk/~gmh/pearl.pdf), you'll see an example of monadic
> programming which is as purely functional as you could ask for.

I don't think Eray was saying that using monads resulted in programs
which aren't purely functional. He was just refering to the difference
between the traditional purely functional programming style vs.
pseudo imperative monadic 'do' programming style. I'm inclined to agree.
For IO or dealing with mutable data in general I can understand the
necessity of monads, but I haven't found much use for them otherwise.

>    What the monad contributes to this parsing library is a more powerful
> form of composition than the standard function-composition operator (.).
> It's ideal for combining parsers sequentially, and my undergraduate classes
> find it far easier to understand than the combination of (>*>) and `build`
> that's presented in Simon Thompson's
> http://www.cs.ukc.ac.uk/people/staff/sjt/craft2e/.
>    It's true that the parsing monad does involve "sequential programming",
> but the sequentiality is inherent in the problem. It's bound to appear, one
> way or another, whenever parsers are combined sequentially. The monadic
> formulation's advantage is that the details of how sequentially combined
> parsers communicate with one another are hidden.

I don't know about the book you're talking about, but I can't see any
reason why you need to make your parser combinators monadic to get
a more powerful (for parsers) form of composition than you get with (.).
IIRC correctly the principal justification for the arrows proposal was
that some sophisticated functional parsing techniques can't be made
monadic? (I forget why now:)

Regards
--
Adrian Hey