imo, the most import ingredient to understand monads, is to understand
lazy evaluation. In Haskell, everything is about values. If you have a
function f :: a -> b, then f x stands for a value of type b (nothing
is evaluated yet).
Now, if you have another function g :: a -> M b, then g x stands for a
value of type M b, that is, a value of type b requiring something more
(encoded by the monad M). Depending on which Monad you used, you need
to do something the the value M b to get to the actual value b. In the
case of the State monad, you have to run it with an initial state. In
the case of IO, you can't do anything and so you have to give the
value to the runtime-system (via the main-function). In the case of
the List monad (which represents non-determinism), you can choose any
element of the resulting list, or, more commonly, use every possible
result (i.e. the whole list).
--
Thomas Danecker
2009/12/29 Maciej Piechotka
On Tue, 2009-12-29 at 02:07 -0800, CK Kashyap wrote:
Thanks Jason,
You should make a `Functor' instance since monads are all functors (though the typeclass does not enforce this).
What are the benefits of making it an instance of Functor?
1. For example to use function of type Functor f => f a -> f d.
2. Also you need Functor to have Applicative which is rather useful (f < $> arg1 <*> arg2 <*> arg3 <*> ... as opposed to return f `ap` arg1 `ap` arg2 `ap` arg3 ..., (*>), (<*) etc.)
3. Because it is functor ;). Every Monad is functor:
instance Functor MyMonad where fmap = liftM instance Applicative MyMonad where pure = return (<*>) = ap
4. If you use Control.Applicative you can find: read <$> getLine I find it much more readable then liftM read getLine (it looks nearly like read $ getLine).
Regards
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe