aditya siram wrote:
My brain turns into strange braid when I see this kind of thing. I don't quite understand it and I've never used it in real world code but I'll try and explain anyway. Caveat emptor.
[..]
Now look at 'n' and imagine it was a memory location. Mentally substitute some hex address (like 0x0000) if it makes it easier.
Another way to look at it is to observe that the result n does not depend on the input n , even though the notation might suggest otherwise. To see that, let _|_ denote an expression that is undefined , i.e. raises an error when you try to evaluate at it. Using the definition data Tree a = Branch (Tree a) (Tree a) | Leaf a label n (Branch a b) = (na+nb, Branch a' b') where (na,a') = label n a (nb,b') = label n b label n (Leaf _) = (1, Leaf n) we have label _|_ (Branch (Leaf 'c') (Leaf 'd')) = (na+nb, Branch a' b') where (na,a') = label _|_ (Leaf 'c') (nb,b') = label _|_ (Leaf 'd') = (1+1, Branch (Leaf _|_) (Leaf _|_)) So, even though the argument n is undefined, the function label still produces a partially defined result. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com