Avoiding "Non-exhaustive patterns in function f"
Haskell is known for its very strong static type checking, which eliminates a lot of runtime errors. But the following simple program crashes at runtime: data D = A | B f A = True main = print (f B) I understand this has nothing to do with type checking, but why can't the compiler give a warning about this? Or is this by design or because it is impossible to check with more complex recursive data types? Thanks, Peter
On Tue, Jun 19, 2007 at 11:03:46PM +0200, peterv wrote:
Haskell is known for its very strong static type checking, which eliminates a lot of runtime errors.
But the following simple program crashes at runtime:
data D = A | B
f A = True
main = print (f B)
I understand this has nothing to do with type checking, but why can't the compiler give a warning about this? Or is this by design or because it is impossible to check with more complex recursive data types?
Like all good UNIX compilers, GHC will only print warnings if you ask it to, with -Wincomplete-patterns (iirc). -Wall enables most of them, the full list is in The Glorious Glasgow Haskell Compilation System User's Guide (a valuable read!) Stefan
On Tue, 19 Jun 2007, Stefan O'Rear wrote:
Like all good UNIX compilers, GHC will only print warnings if you ask it to, with -Wincomplete-patterns (iirc). -Wall enables most of them, the full list is in The Glorious Glasgow Haskell Compilation System User's Guide (a valuable read!)
Since GHC is not a C compiler (philosophy: "the programmers knows what he does") but a Haskell compiler (philosophy: "assist the programmer on finding mistakes") the warnings should be on by default, to encourage good programming style and find mistakes early. "Non-exhaustive patterns" often indicates possible situations for crashes. "unused identifier" often indicates that one has not completed the implementation of a function. Unfortunately GHC-6.4 warns about unnecessarily imported modules, but when you remove the import statement, some identifiers are missing.
| Unfortunately GHC-6.4 warns about unnecessarily imported modules, but when | you remove the import statement, some identifiers are missing. If that is still the case with 6.6.1, please do submit a bug report and example. Thanks! Simon
On 6/19/07, peterv
I understand this has nothing to do with type checking, but why can't the compiler give a warning about this? Or is this by design or because it is impossible to check with more complex recursive data types?
Take a look at Catch from Neil Mitchell: http://www-users.cs.york.ac.uk/~ndm/catch/ . -- Felipe.
Hi
I understand this has nothing to do with type checking, but why can't the compiler give a warning about this? Or is this by design or because it is impossible to check with more complex recursive data types?
Take a look at Catch from Neil Mitchell: http://www-users.cs.york.ac.uk/~ndm/catch/ .
Using the released version of Catch on the example you gave: Analysing Checking [1/1]: Main: Pattern match failure in function at 5:1-5:10. Partial: "Main.f" Partial: "Main.main" Partial: "main" Answer: 0 This says: the error message you will get is about a pattern match on line 5 (that's where 'f' is in the example program). The list of partial functions, in some kind of call-stack order, is Main.f, then Main.main - i.e. your main function calls f which is partial. Answer 0 means "the necessary precondition for safety is false" - or its not safe at all. If you turn on logging Catch will additionally tell you that the precondition on 'f' is that the data structure must be a 'A' constructed value. Thanks Neil
I understand this has nothing to do with type checking, but why can't
Super! Would be nice if this gets build into GHC/GHCI :) -----Original Message----- From: Neil Mitchell [mailto:ndmitchell@gmail.com] Sent: Wednesday, June 20, 2007 01:07 To: Felipe Almeida Lessa Cc: peterv; haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Avoiding "Non-exhaustive patterns in function f" Hi the
compiler give a warning about this? Or is this by design or because it is impossible to check with more complex recursive data types?
Take a look at Catch from Neil Mitchell: http://www-users.cs.york.ac.uk/~ndm/catch/ .
Using the released version of Catch on the example you gave: Analysing Checking [1/1]: Main: Pattern match failure in function at 5:1-5:10. Partial: "Main.f" Partial: "Main.main" Partial: "main" Answer: 0 This says: the error message you will get is about a pattern match on line 5 (that's where 'f' is in the example program). The list of partial functions, in some kind of call-stack order, is Main.f, then Main.main - i.e. your main function calls f which is partial. Answer 0 means "the necessary precondition for safety is false" - or its not safe at all. If you turn on logging Catch will additionally tell you that the precondition on 'f' is that the data structure must be a 'A' constructed value. Thanks Neil No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.9.1/854 - Release Date: 19/06/2007 13:12 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.9.1/854 - Release Date: 19/06/2007 13:12
participants (6)
-
Felipe Almeida Lessa -
Henning Thielemann -
Neil Mitchell -
peterv -
Simon Peyton-Jones -
Stefan O'Rear