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. 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.
... whenever I use monads, I feel like going back to an imperative language because it will make my program much less concurrent.
Not necessarily. In the case of two parsers combined in sequence, there's no concurrency to begin with, but Parser also belongs to MonadPlus, which provides for nondeterministic --i.e., concurrent-- choice. --Ham ------------------------------------------------------------------ Hamilton Richards Department of Computer Sciences Senior Lecturer Mail Code C0500 512-471-9525 The University of Texas at Austin Taylor Hall 5.138 Austin, Texas 78712-1188 ham@cs.utexas.edu hrichrds@swbell.net ------------------------------------------------------------------