Removal candidates in patterns

[Aaron Denney]

On 2006-01-26, Olaf Chitil <O.Chitil at kent.ac.uk> wrote:
>
> I am very please to see on the Wiki also a list of removal candidates 
> and that these include n+k patterns and ~ patterns.
>
> I'd like to add one pattern to this list of removal candiates: k 
> patterns, that is, numeric literals.

I don't see that much use for the first two but I really want to
argue for being able to pattern-match on numeric literals.  I think
numeric literals should be treated as much as possible as if there were
declarations like "data Int = 0 | 1 | (-1) | 2 | (-2) | ..."

Or am I misunderstanding the suggestion here?

> Iff n+k patterns are removed, there is little good use for k patterns 
> either.

Say what?  n+k could perhaps serve some pedagogical purpose in
presenting the peano numbers.  Plain old literals are not so tied to
a particular representation (that is, you can imagine 4 being expanded
to match Int# 4, or BooleanSequence [T,F,F] internally, or whatever and
still looking exactly the same in the code), and have the same utility
as being able to pattern-match any data.

> So get rid of these three and pattern matching becomes so much more simple.

>From the point of view of Hat, yes.  Despite how useful hat is, I'd
rather have the ability to do 

ack 0 n = n+1
ack m 0 = ack (m-1) 1
ack m n = ack (m-1) (ack m (n-1))

which looks far nicer than

ack m n | m == 0 = n + 1
        | n == 0 = ack (m-1) 1
        | otherwise = ack (m-1) (ack m (n-1))

I admit this is 99% aesthetics, but aesthetics do matter, as does
consistency and regularity.  And there are some cases where the guards
can get quite complex, especially when rewriting something that already
combines pattern-matching with guards.

-- 
Aaron Denney
-><-