Re: Exhaustive Pattern-Matching
Dnia czw 28. sierpnia 2003 16:37, Frank Atanassow napisa: SML has the same limitations w.r.t. guards as Haskell; Haskell compilers can and do check exhaustiveness, but not redundancy because matches are tried sequentially. I believe SML matching is also sequential. If there is a difference between the two, it must have to do with laziness. SML doesn't have guards at all. Most Haskell matches are correctly flagged as non-exhaustive or redundant if you use otherwise instead of relying on some guards themselves being exhaustive (which the compiler can't check). -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
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
Re: Exhaustive Pattern-Matching
G'day all. 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? (We can move this to glasgow-haskell-users if you like.) Cheers, Andrew Bromage ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Exhaustive Pattern-Matching
Thank you all for your help. I will try this ghc-flag. It is interesting as well, that in contrast to Haskell Standard ML ensures, that pattern-matches are exhaustive and irredundant. Ciao, Steffen ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Exhaustive Pattern-Matching
On Thursday, Aug 28, 2003, at 08:47 Europe/Amsterdam, Steffen Mazanek wrote: Thank you all for your help. I will try this ghc-flag. It is interesting as well, that in contrast to Haskell Standard ML ensures, that pattern-matches are exhaustive and irredundant. SML has the same limitations w.r.t. guards as Haskell; Haskell compilers can and do check exhaustiveness, but not redundancy because matches are tried sequentially. I believe SML matching is also sequential. If there is a difference between the two, it must have to do with laziness. Regards, Frank ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Exhaustive Pattern-Matching
I have a question about pattern-matching. In the Haskell-report it is not postulated, that pattern matching has to be exhaustive. Would it be possible at all to implement an algorithm, which checks Haskell-style patterns for exhaustiveness? What kinds of complication can be expected? Maybe you have some pointers to other resources about this topic. 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. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Exhaustive Pattern-Matching
hello, Steffen Mazanek wrote: Hello, I have a question about pattern-matching. In the Haskell-report it is not postulated, that pattern matching has to be exhaustive. Would it be possible at all to implement an algorithm, which checks Haskell-style patterns for exhaustiveness? What kinds of complication can be expected? Maybe you have some pointers to other resources about this topic. Thank you, Steffen i believe in general this is undecidable, as one can have arbitrary decisions in guards. of course in practise this is probably not much of a problem, so the compiler could (and often does) give useful warnings. so at the end of the day the usefulness of an algorithm to detect incomplete patterns depends on what you want to do with it. bye iavor -- == | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | == ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
