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
_______________________________________________
Haskell-prime mailing list
[email protected]
http://haskell.org/mailman/listinfo/haskell-prime
