Removal candidates in patterns

[Duncan Coutts]

On Thu, 2006-01-26 at 19:35 +0000, Olaf Chitil wrote:
> 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?

Isn't the same true for:

foo n | n == 0    = ...
      | otherwise = ...

It's still going to fail for negative numbers.

> 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.

The above example is still defined for all numeric types.

Eliminating that syntax form doesn't remove those problems.

> 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).

I'm in favour of removing n+k patterns too.

> 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.

Char is a type that is not constructed recursively and yet no one seems
to have problems with character literals as constructors and thus as
patterns. Each character literal is a Char constructor. Why can't each
numeric literal be a constructor for the numeric types?

I think it's a perfectly reasonable mental model for people to believe
that:
data Char = 'a' | 'b' | 'c' | ...
data Int  = ... -2 | -1 | 0 | 1 | 2 | ...

I don't see why we should remove one and not the other. Students will
ask why the can pattern match on strings, characters and booleans but
not numbers.

Perhaps primitive recursion on integers is misleading, but people will
still write

foo n | n == 0    = ...
      | otherwise = ...

where they previously wrote

foo 0 = ...
foo n = ...

so what have we gained except less notational convenience?

Not all pattern matching on numeric literals is involved with recursion
on integers, where as virtually all n+k patterns is used for that
purpose. So there is some distinction between the two forms. n+k
patterns are a quirk of the numeric types. k patterns are regular with
other types in the language.

> 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.

It's partly the complexity of the language and partly because our latest
language spec (H98) is not the language that we all use (H98 + various
extensions). I'm sure Haskell-prime will help in this area.

I don't mean to belittle the difficulty of building tools. I know how
hard it is, I'm trying to build one too.

Duncan