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 p
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 (x@(x,
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, a
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
