Why, then, not permit such definitions only for members of Eq?
My thoughts:
- because it will break an important invariant indicated by Martin,
namely the one that says that pattern variables are not forced
- it will make efficient compilation of pattern matching much harder
- it will make the termination behavior of pattern matching dependent
not only on the term being matched, but also on how Eq is implemented
for that type
- it will make the very rules of evaluation for pattern matching much
more complex, fragile and hard to understand: in what order should the
equated parts be evaluated? That influences termination behavior, so
it is important. In what order should equality comparisons be
performed in
f (Node a (Leaf b a) (Node a))) = b
?
2009/5/15 Salvador Lucas
Dear Martin,
I think that the (practical) reason is avoiding equality checks during pattern matching.
For instance, how do you evaluate this:
foo ((+1):(1+):[]) ?
Both expressions in the first and second entries of the list are semantically equivalent, but from an operational point of view, you have to ensure the equality of two functions over an infinite domain (of integer numbers).
Best regards,
Salvador.
Martin Hofmann escribió:
It is pretty clear, that the following is not a valid Haskell pattern:
foo (x:x:xs) = x:xs
My questions is _why_ this is not allowed. IMHO, the semantics should be clear: The pattern is expected to succeed, iff 'x' is each time bound to the same term. Isn't this allowed, because this would require a strict evaluation of the 'x' variables?
Thanks,
Martin
_______________________________________________ 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
-- Eugene Kirpichov Web IR developer, market.yandex.ru