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