Removal candidates in patterns

[Ian Lynagh]

On Thu, Jan 26, 2006 at 07:35:42PM +0000, Olaf Chitil wrote:
> 
> As response to both Aaron and Duncan,
> 
> >foo 0 = ...
> >foo n = ...
> > 
> >
> And what about the negative numbers?

(I agree with Duncan re this).

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

Haskell (FSVO "Haskell") has several types for natural numbers: Word8,
Word16, Word32, Word64. I'd also like to see a Natural type (analogous
to Integer) (you might also argue for Word, analogous to Int), and I'd
like to use k patterns with all of them.

A Natural class would also make some sense. Then we could have, e.g.,
    (^) :: (Num a, Natural b) => a -> b -> a
although that does cause problems with Haskell's libraries being
strongly biased towards Int (and changing that probably breaks an awful
lot of code).

However, it would seem odd to me, as a new user, that I could say

foo 1 = 0
foo n = n

but not

foo (-1) = 0
foo n = n

On n+k patterns, I think they make code a lot more concise and easier to
read, as well as allowing code to match specifications much more
closely. In fact, every reason why in a mathematical definition you
would say
    f (x+1) = g x
rather than
    f x | x >= 1 = g x'
        where x' = x - 1
applies equally to code IMO.

I think there is something to be said for making n+k patterns have a
Natural type rather than an Integral type, though, as we are requiring
that n be at least 0.

k patterns are less clear cut due to Rational, but on balance I'd be
happy with k patterns being Integral only as people writing
    f 1.1 = 0
probably normally don't really mean that.

So in conclusion, I'm in favour of keeping both n+k and k patterns, and
restricting n+k patterns to Natural types and k patterns to Integral
types.

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

I don't think this makes it significantly harder to make tools, there is
a simple source transformation to eliminate these constructs (your
reasons for disliking using it I didn't fully understand). If tools like
hat think of these constructs as, and shows them to the user as, their
expanded versions then we would be no worse off than if they weren't in
the language.


Thanks
Ian