get the best and fastest answer
|
|
|
|
Clear questions and runnable code get the best and fastest answer |
|
| PerlMonks |
comment on |
| ( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
|
It seems like your entire article would make a lot more sense if every instance of the word "monads" was replaced with "the IO monad". There are other monads, you know. Sequencing IO actions is probably the worst example of a monad, because it gives the least insight into how monads in general are put together and used. (In particular, the IO monad is primitive in Haskell by necessity, but it's the only monad like that.)
It seems like an especially useless abstraction to be making if you only have that one example, and you're coming from an imperative background (like perl), which is quite a lot like working in the IO monad all the time. If you'd like to see other examples of monads and what they're good for, I highly recommend starting off with a look at Parsec, which is a library for parsing implemented in Haskell (and then reimplemented in a bunch of other languages). A simpler decent example is the list monad, which gives you what are essentially list comprehensions, or what computer scientists call nondeterministic computations. Also, having the monadic abstraction lets you write algorithms which are generic over a wide class of monads, and then apply those at specific monads for a variety of effects. Let me give a somewhat involved example, so you can hopefully get a sense for what I mean. A friend and I wrote an L-system fractal generator which was nondeterministic, in the sense that each rule gave a list of possible expansions for a symbol, and it enumerated all possible expansions of the L-system. For display on the screen however, we wanted to choose a random one. Generating the whole list was wasteful, so rather than do that, we replaced the lists of rules in the input to the algorithm with computations in a random-generation monad which would emit one of the results in the original list at random. Since the expansion algorithm itself was generic over monad, only the input to it had to change, and we had a randomised L-system generator. Similar changes to the input could be made to incorporate state transitions into the expansion of the L-systems (or even continuations, if you're crazy), all without changing the code that actually does the expansion. So what are monads really? They're embedded domain specific languages which have been constructed to conform to a particular basic structure so that various control structures and generic algorithms can be shared across those embedded languages. There are lots of good examples in Control.Monad. For instance, forM/mapM is essentially a for-each loop which works in any monad. This saves you the trouble of implementing a new for-each loop in every new EDSL you write. That is, when you're implementing your EDSL, if you just bother to implement return and bind, you immediately get a nice API of control structures for free. Implement mzero and mplus, and you get an instance of MonadPlus, which gives you a bunch more. By encouraging people to write and use EDSLs (which are essentially just really good APIs) you encourage people to write code which is closer to the domain, and hence easier to think about. I/O is a red-herring -- I/O is handled by a monad in Haskell not because it's absolutely necessary that it be handled by a monad, but because it's possible, and so you get all the basic control structures for I/O from that same monad library for free. In reply to Re^2: Is it worth using Monads in Perl ? and what the Monads are ?
by Anonymous Monk
|
|