RE: Exhaustive Pattern-Matching
On Wed, Aug 27, 2003 at 04:57:27PM +0100, Simon Marlow wrote: GHC tries to do so, but sometimes gets it wrong. See the -fwarn-incomplete-patterns flag. We'd appreciate it if someone could overhaul this code - it's been on the wish list for a long time. As a matter of curiosity, do you have some examples as to when GHC gets it wrong? There's one in the bug database: http://sourceforge.net/tracker/index.php?func=detailaid=485324group_id =8032atid=108032 And I think a couple more have been reported on ghc-bugs, Google should be able to find them. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Exhaustive Pattern-Matching
GHC tries to do so, but sometimes gets it wrong. See the -fwarn-incomplete-patterns flag. We'd appreciate it if someone could overhaul this code - it's been on the wish list for a long time. Indeed, I always try to avoid all warnings in my sources by using the flag -Wall, because I consider this to be good programming style. (In particular warnings about unused and shadowed variables prevented a lot of errors.) However some warnings are difficult to avoid. So how difficult would it be to implement non-exhaustive pattern warnings for nested patterns? data Color = Red | Green | Blue f :: Color - String f x = case x of Red - r _ - ++ case x of Green - g Blue - b Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: Red Red in the second case is unreachable (and this should also be worth a warning.) Christian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Exhaustive Pattern-Matching
Christian Maeder [EMAIL PROTECTED] writes: Indeed, I always try to avoid all warnings in my sources by using the flag -Wall, because I consider this to be good programming style. (In particular warnings about unused and shadowed variables prevented a lot of errors.) However some warnings are difficult to avoid. So how difficult would it be to implement non-exhaustive pattern warnings for nested patterns? data Color = Red | Green | Blue f :: Color - String f x = case x of Red - r _ - ++ case x of Green - g Blue - b One way to do it, is to add _ - error This can never happen I do this occasionally, and it catches some errors or mistaken assumptions on my part every now and then. (Perhaps one could even have a special funcition, impossible, say, that would tell the compiler that a particular branch would never be taken. In case the compiler is smart enough to figure it out, and issue a warning for it -- it would know not to bother.) Or one might wish for some kind of pragma to turn off this warning selectively for a block of code. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Exhaustive Pattern-Matching
Back when I hacked on Hugs routinely, I thought of detecting uncaught cases including things like the following: f :: Color - String f x = case x of Red - r _ - ++ case x of Green - g Blue - b Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: Red Red in the second case is unreachable (and this should also be worth a warning.) My plan for how to do it was as follows: 1) In an early phase, insert an easily identified default error case: f :: Color - String f x = case x of Red - r _ - ++ case x of Green - g Blue - b _ - hugs_PMF location info _ - hugs_PMF location info 2) In later phases, delete any obviously redundant case alternatives. In this example, this would restore the code to what Christian wrote. We could warn when deleting a human-provided case alt but this might be a bad idea since it would penalize defensive programming. If Hugs performed inlining, we would want to be careful not to report the same missing case alt more than once but we would also want to allow inlining and other optimizations to have a shot at detecting that a case alt is unreachable. One of the simplest ways of doing this would be to keep a list of which problems have already been reported and not report the same problem twice. Other ways exist. 3) Warn if any occurences of hugs_PMF remain and report any runtime failures that miss hugs_PMF as compiler bugs. I never implemented this but I think it would work well. -- Alastair Reid ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
