Eu defini uma árvore binária:

data Tree = Null | Node Tree Int Tree

e implementamos uma função que produzirá a soma dos valores de todos os seus nós:

sumOfValues :: Tree -> Int
sumOfValues Null = 0
sumOfValues (Node Null v Null) = v
sumOfValues (Node Null v t2) = v + (sumOfValues t2)
sumOfValues (Node t1 v Null) = v + (sumOfValues t1)
sumOfValues (Node t1 v t2) = v + (sumOfValues t1) + (sumOfValues t2)

Funciona como esperado. Eu tive a idéia de também tentar implementá-lo usando guardas:

sumOfValues2 :: Tree -> Int
sumOfValues2 Null = 0
sumOfValues2 (Node t1 v t2)
    | t1 == Null && t2 == Null  = v
    | t1 == Null            = v + (sumOfValues2 t2)
    |               t2 == Null  = v + (sumOfValues2 t1)
    |   otherwise       = v + (sumOfValues2 t1) + (sumOfValues2 t2)

mas este não funciona porque eu não implementeiEq, Acredito:

No instance for (Eq Tree)
  arising from a use of `==' at zzz3.hs:13:3-12
Possible fix: add an instance declaration for (Eq Tree)
In the first argument of `(&&)', namely `t1 == Null'
In the expression: t1 == Null && t2 == Null
In a stmt of a pattern guard for
             the definition of `sumOfValues2':
        t1 == Null && t2 == Null

A questão que precisa ser feita, então, é como Haskell pode fazer a correspondência de padrões sem saber quando um argumento passado é correspondido, sem recorrer aEq?

Editar

Seus argumentos parecem girar em torno do fato de que Haskell não está realmente comparando os argumentos da função, mas sim na "forma" e nos tipos de assinatura para saber qual sub-função corresponder. Mas que tal isso?

f :: Int -> Int -> Int
f 1 _ = 666
f 2 _ = 777
f _ 1 = 888
f _ _ = 999

Ao executarf 2 9, não terá que usarEq saber qual das subfunções é a correta? Todos eles são iguais (ao contrário do meu exemplo inicial de árvore, quando tínhamos Árvore / Nó / Nulo). Ou é a definição real de umInt algo como

data Int = -2^32 | -109212 ... | 0 | ... +2^32 

?