[GHC] #13635: Incorrect result at runtime with list comprehensions in that case
GHC
ghc-devs at haskell.org
Mon May 1 15:29:28 UTC 2017
#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.html
#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.html
#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
More information about the ghc-tickets
mailing list