> | Another strange thing about n+k patterns.
> |
> | Its definition uses >= , but >= is not part of the class Num.
> | Does that mean that n+k patterns have to be instances of class Real?
>
> Certainly. In fact, they're really meant to apply only to class
> Integral (and it would be natural numbers, if we had them).
Although I'm not surprised about this claim, I think it is a bit against
the Haskell spirit: for the definition of n+k patterns you need ">=" and
"-" which determines the class in which they are defined. My remark was
that in this spirit the use of >= goes farther than necessary.
Analogy: restrict the use of foldr to homogeneous (type a->a->a) operators?!
> | One could leave it class Num, if the translation were expressed
> | in terms of "signum" rather than ">=".
>
> Being able to match complex numbers (along the positive real axis only!)
> with n+k patterns would be a dubious advantage, IMHO.
There is no instance of Ord for complex numbers in the Prelude [unless
I've missed something], thus they cannot be used (yet) with n+k patterns.
If you order them pointwise, i.e.
a:+b <= c:+d = a<=c & b<=d
then they match the right upper quadrant and not just the real axis.
In fact you need a rather strange ordering to make them just match the
real axis.
IMHO it is not more or less strange to use n+k patterns with
complex numbers than it is to use them with real or rational numbers.
> | Question:
> | Can one misuse the feature of n+k-patterns to simulate
> | n*k+k' patterns? [I am talking about weird user-defined
> | instances of Num.]
>
> quite possibly.
If we instantiate Num/Ord by setting "negate" to the identity function,
+ to integer division and >= to the divisibility predicate, then
an n+k pattern actually means n*k.
Looks as if the n+k-pattern gave us the old "views" back,
although only in a very restricted form.
--
Stefan Kahrs
