Removal candidates in patterns
wnoise at ofb.net
Thu Jan 26 13:32:09 EST 2006
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
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.
More information about the Haskell-prime