Removal candidates in patterns

[Olaf Chitil]

As response to both Aaron and Duncan,

>foo 0 = ...
>foo n = ...
>  
>
And what about the negative numbers? For negative numbers the second 
equation matches, which in 90% of all cases in practise has never been 
written for them. Aaron's Ackerman function disappears in infinite 
recursion... Besides, what is ack 0.5 0.5?

The use of n+k patterns, but also the definition pattern above wrongly 
lead programmers to believe that they are dealing with natural numbers. 
There is no nice primitive recursion for integers. Even worse, without a 
type signature restricting its type, foo will be defined for all numeric 
types. For Float or Rational it makes hardly any sense.

If Haskell had a type for natural numbers I'd be in favour of n+k and k 
patterns (working only for this type, not any other numerical type).

Using primitive recursion on integers or even arbitrary numbers is 
misleading. You can teach primitive recursion nicely for algebraic data 
types, because the recursive pattern of the function definition follows 
the recursive pattern of the type definition.


With respect to tools of which Hat is one example: If it is hard to 
build tools, then less tools will be built. Compare the number of tools 
for Scheme with those for Haskell. Most tools grow out of student 
projects  or research projects;  these have  rather limited resources.

Ciao,
Olaf