> > P.S. Monads are a great idea for expressing operations analogous > > to iterators and database queries within a pure functional language. > > The bad idea in Haskell was applying them to general imperative > > programing a la Haskell IO/ST monads. > > Tim, could you elaborate on this? I've always found Monads hard to > understand. Shifting to this other context might help tremendously.
I have a marvelous proof of this, but this email is too small to contain it. However, this point becomes self-evident after about 100 hours of programming in Haskell. I recommend doing that, even if you never plan to use Haskell again. In Haskell, I find that pure functional code that processes arrays using comprehensions often becomes 5X simpler than equivalent C++ code: it really is that much less code and that much easier to write and to read. The simplicity results from the intuition we all have for defining variables drawn from collections and then conditionally manipulating them. But if you have to take multiple monadic actions simultaneously -- e.g. mixing option types and array comprehensions, or I/O effects and array comprehensions, the code becomes dramatically harder to read or write, though only incrementally larger. This is the result of having to specify compositions of monads, and to lift nested comprehensions using operations appropriate for the current context. -Tim _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
