Removal candidates in patterns
O.Chitil at kent.ac.uk
Thu Jan 26 14:35:42 EST 2006
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.
More information about the Haskell-prime