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 <w...@freegeek.org> wrote: > 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 >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe