There are two separate parts I propose, the second one I'm less sure of, but they're somewhat related. 1. Allow empty case, i.e. "case some_variable of { }" (GHC ticket [1]). This adds consistency, it always causes a pattern-match error, and it is a sensible way to look at all the cases of types with no constructors (recall EmptyDataDecls will probably be in Haskell' [4]) -- especially for automatic tools (or programmers familiar with dependent types; GADTs have some of these effects :-)). Presumably, any time that some_variable could be non-bottom, GHC will warn about the incomplete patterns :-). 2. When a type signature for a function is given, allow to not define any patterns (GHC ticket [2]). The result of calling the function is a pattern match failure (presumably the source-location given for the match failure will be the location of the type-signature). This can also be useful for calling functions before implementing them, helping the type-checker help me do incremental work (again, obviously produces a warning if the function could possibly be non-bottom). However I can think of a few things this (proposal 2) could interfere with: 2.i. Implementing a class method, will you get the default if that method has a default? Actually it turns out to be forbidden... class C n where foo :: n -> n foo = id instance C Int where foo :: Int -> Int --even if we define foo here too, it's an error: --misplaced type signature (perhaps thanks to improved --error messages, thanks simonpj! [5]). --Anyway, I think type signatures ought to be allowed here. I propose to allow type-signatures in instances, which must be equivalent to the signature in the class declaration after the class's signature is specialized to the particular instance type(s). If such a type-signature is found, allow the function to be defined as normal, which includes, if there are no patterns, an error if proposal 2 isn't adopted, and a pattern-match failure if proposal 2 is adopted. (also it turns out that pattern bindings aren't allowed in instances, such as {instance C Int where (foo) = negate}, but I can't say I have a compelling use-case for that!:-)) 2.ii. It could interfere with another feature request of mine (though I'm not sure I want it anymore) (GHC ticket [3]) : I'd like it to be allowed to give a (possibly more restrictive?) type signature at the top level of a module, to a function imported unqualified. Obviously in this case I don't want the function to be treated as pattern-match failure; but I think we can tell the difference because the name is in-scope in this case. Luckily there is no negative interaction with my related proposal to simply allow multiple equivalent type-signatures anywhere one of them is allowed in a declaration-list. So actually, in summary I can't really see anything wrong with proposal 2, especially if my proposal under 2.i. is adopted. [1] http://hackage.haskell.org/trac/ghc/ticket/2431 [2] http://hackage.haskell.org/trac/ghc/ticket/393 [3] http://hackage.haskell.org/trac/ghc/ticket/1404 [4] http://hackage.haskell.org/trac/haskell-prime/wiki/EmptyDataDecls [5] http://hackage.haskell.org/trac/ghc/ticket/1310