[GHC] #13635: Incorrect result at runtime with list comprehensions in that case
#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 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: -------------------------------------+------------------------------------- 1. With GHC 8.0.2\\ {{{ Prelude> [x | x <- [_, _], False] <interactive>:1:12: error: * Found hole: _ :: t Where: `t' is a rigid type variable bound by the inferred type of it :: [t] at <interactive>:1:1 * In the expression: _ In the expression: [_, _] In a stmt of a list comprehension: x <- [_, _] * Relevant bindings include it :: [t] (bound at <interactive>:1:1) <interactive>:1:15: error: * Found hole: _ :: t Where: `t' is a rigid type variable bound by the inferred type of it :: [t] at <interactive>:1:1 * In the expression: _ In the expression: [_, _] In a stmt of a list comprehension: x <- [_, _] * Relevant bindings include it :: [t] (bound at <interactive>:1:1) Prelude>\\ }}} This result makes no sense here.\\ The result will always be the empty list [].\\ 2. With GHC 7.6.3\\ {{{ Prelude> [x | x <- [_, _], False] <interactive>:2:12: Pattern syntax in expression context: _ <interactive>:2:12: Pattern syntax in expression context: _ Prelude> }}} This result also makes no sense here.\\ Similarly this result will always be the empty list []. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13635 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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
#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 vanto): Hello goldfire,\\ yes, I agree with you. It is not a bug. However this behavior is irrational. Reason has disappeared, good sense no longer exists.\\ See ticket #13557.\\ In this ticket simonpj said " I think this is correct behaviour".\\ Yes simonpj, this behavior is correct since you coded it as well! The compiler is stupid, where is the good sense? \\ It is because this good sense did not appear in GHC 7.6.3 that this continues. The compiler would have a better behavior, with more good sense, if "typed holes" was set off as of launch, I think.\\ If you want to comment before I close the ticket, thank you. Soon I open a new feature request ticket to repeat this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13635#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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
#13635: Incorrect result at runtime with list comprehensions in that case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by vanto): * status: new => closed * resolution: => invalid Comment: Hello bgamari,\\ Thank you all for your views. Well from my point of view it is best not to have Typed holes activated by default. It is preferable to let the programmer activate it if needed. Enable it by default, It's like putting the cart before the horses.\\ But it is a minor matter.\\ Good sense is common to every person and sometimes is difficult to explain.\\ I close the ticket and will not open new feature request.\\ -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13635#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13635: Incorrect result at runtime with list comprehensions in that case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by vanto): * Attachment "concrete_example.txt" added. a similar behavior -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13635 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC