[Haskell-cafe] conflicting variable definitions in pattern
ekirpichov at gmail.com
Fri May 15 04:34:21 EDT 2009
Why, then, not permit such definitions only for members of Eq?
- 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
f (Node a (Leaf b a) (Node a))) = b
2009/5/15 Salvador Lucas <slucas at dsic.upv.es>:
> 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,
> 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?
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
Web IR developer, market.yandex.ru
More information about the Haskell-Cafe