Christian wrote:
Frank A. Christoph gave examples for unintended non-linear patterns,
among them:
Or, even more more common:
f (x@(x,y)) = ... --- oops!
If I don't oversee something obvious, this just would fail to
type-check, so this shouldn't be a problem.
As you can plainly see,
Frank A. Christoph gave examples for unintended non-linear patterns,
among them:
Or, even more more common:
f (x@(x,y)) = ... --- oops!
If I don't oversee something obvious, this just would fail to
type-check, so this shouldn't be a problem.
Christian Sievers
In addition to the other arguments mentioned, there is the practical concern
that it becomes quite easy to introduce non-termination by a simple typo:
f [1...] [2..] where f x x = x --- oops!
versus, say, the intended
f [1..] [2..] where f x y = x .
Or, even more more common:
f
As far as I remember, this was considered by the original Haskell committee
in 1988.
The argument then against non-linear patterns was that, in the interests of
equational reasoning, it
was desirable to define a function using disjoint cases, and there was no
way of defining,
using a pattern,
Just to add to the list of reasons against non-linear patterns:
In term rewriting, they have a number of known negative properties.
- non-overlapping rules may fail to be confluent, but only in the presence
of non-linear patterns (non-orthogonality) [mentioned by Bjorn]
- the disjoint union of
Term rewriting theory indicates that non-linear patterns should be treated
with care. For instance, a term rewriting systems with a non-linear rule
will in general not have a normalizing rewrite strategy which is sequential,
and nonlinear term rewriting systems are not orthogonal which means they
