For me, the following two things did the magic, so I'll suggest them: 1. Writing a recursive function that takes a binary tree and returns the same tree, but with its leaves enumerated. Each function call takes the tree and the counter and returns the resulting tree and the new counter value. The pattern that emerges is similar to the state monad. The pattern shows that the order of the recursive calls is not ambiguous, unlike in a function that just counts the leaves, for example. Changing the order of the recursive calls changes the result. (code below) 2. Putting the above pattern into a datatype and rewriting the apply-funtion for this datatype (>>=) allows only to apply funtions in a non-ambiguous way. Not giving a deconstructor for the IO monad forces the programmer to decide in which order calls to IO functions have to be done. I hope this is clear enough; I was able to use the IO monad at the moment I realized that Haskell uses this kind of "trick" to ensure that the order of execution of function arguments is always well-defined and never ambiguous. Of course, there is much more about monads, but this was my entry point. Best regards Daniel code (tree enumeration): data Tree a = Leaf a | Node (Tree a) (Tree a) deriving Show enumTree n (Node a b) = let (n', a') = enumTree n a in let (n'', b') = enumTree n' b in (n'', Node a' b') enumTree n (Leaf x) = (n+1, Leaf n) aditya siram schrieb: Hi all, |
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe