Removal candidates in patterns

[Claus Reinke]

> Olaf Chitil wrote:
>> I'd like to add one pattern to this list of removal candiates: k 
>> patterns, that is, numeric literals.

I was rather shocked when I first read this. And I certainly don't
like the argument from implementation difficulties in a certain tool!-)

I don't mind losing (n+k), not because it wasn't neat, but it looks like
a special case needing a more general solution, beyond Haskell''s scope.

I don't want to lose numeric literals in patterns! But, having recovered
from the first shock, and ignoring other people's hats, there may be a
few things that need cleaning up in that area (why do some patterns
work without Eq, some with? Should there be a Match class or 
something to pin down what can and what can't be matched how?..).

> Let's remove higher order functions too, they are tricky to
> implement. :)

it seems so, at least for pattern matching "numeric literals"; what is the
result of (f 1) and (g A) in the following code?

... -- some code omitted here

f 1 = True
f n = False

g A = True
g n = False

and should it depend on the context (types, instances, ..), or not?

run the following through ghci with and without the signature for f, 
and with either version of (==) for functions; and what happens if
we uncomment the Eq instance for D? is that all as expected?

cheers,
claus

---------------------------------------------------
module K where

import Text.Show.Functions

instance Eq (a->b) where
  f == g = False
  -- f == g = True

instance Num b => Num (a->b) where
  fromInteger n = const $ fromInteger n

-- f :: Num b => (a->b) -> Bool
f 1 = True
f n = False

main = print $ (f 1,g A)

-------------

data D = A | B -- no Eq, but matching allowed

-- instance Eq D where a == b = False

g A = True
g n = False