#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 goldfire): And with `-fdefer-typed-holes`, you get the behavior that you want. (But be aware of [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts... #deferred-type-errors-in-ghci this restriction] about deferred type errors and GHCi.) I argue that GHC's behavior in both cases is correct. As the [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts... #typed-holes manual] says, a hole terminates compilation without `-fdefer- typed-holes`. So the GHC 8.0.2 behavior agrees with the specification. As there were no typed holes in GHC 7.6.3, a `_` in an expression really is invalid syntax, so terminating with an error is appropriate there, too. With `-fdefer-typed-holes`, you will still get warnings about the holes in your code. But you can suppress these with `-Wno-typed-holes`. My guess is that `{-# OPTIONS_GHC -fdefer-typed-holes -Wno-typed-holes #-}` will get you exactly the behavior you want. If you agree with this analysis, please close the ticket. Thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13635#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler