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