Yes I think that showing the Maybe and List implementation of monads is
essential. They're practical and in a lot of ways they represent two
completely different types of computation demonstrating the flexibility of
the Monad abstraction. Thanks for that suggestion.
-deech
On Mon, Aug 9, 2010 at 4:33 AM, wren ng thornton
aditya siram wrote:
Thanks all for you suggestions! Upon further reflection I realized that my audience is more pragmatic than theoretical. Instead of emphasizing how monads are constructed and the monad laws I think I want to dive right into the most common and useful monads.
From my vantage point they are (in no particular order) : Reader, Writer,
State, IO, ST, STM, Parsec (have I missed any?) and of course the transformer versions. I am debating whether or not to add [] to the bunch.
Whether you add [] or not, you should definitely include Maybe. Maybe captures the most basic kind of fallible computation, so it shows up all over the place with pragmatic coding. Compare against null pointers, returning -1 to signal error when a positive number is the expected return, using 0 to express an infinite limit on some kind of resource, etc. Maybe does the same thing, except it does them cleanly and correctly because we express the possibility of failure in the type system instead of relying on "magic values" to express them. Magic values are even worse than magic numbers and other magic constants, IMO.
Once you've explained Maybe, you can mention (Either a) in passing; they should figure out the generalization immediately.
-- Live well, ~wren
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe