#13635: Incorrect result at runtime with list comprehensions in that case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): vanto, why, concretely, do you think this is irrational? In general it is impossible for the compiler to know whether any given subexpression of your program will be evaluated. Consequently, we make no effort to adjust error messages for reachability (except when reachability can be determined by type information, e.g. pattern matching on a GADT). Typed holes are intended to be an aid to development and really shouldn't be found in production code. GHC's default behavior, like that of most compilers, is to assume the user is compiling for a production setting. The compiler's default treatment of typed holes reflects this. If you want the program to compile despite holes then we offer `-fdefer-typed-holes`. If you feel like this default should be changed then perhaps we can discuss this, but I'll admit I'm rather skeptical. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13635#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler