I'm with Neil on this. Suggestion 1 is great, whereas suggestion 2
just makes it easier to make mistakes, and that's not what we want.
On Fri, Aug 15, 2008 at 6:34 PM, Isaac Dupree <[EMAIL PROTECTED]> wrote:
> 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
> Haskell-prime@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
