[GHC] #13557: error found hole: _ is not appropriate in the following case
#13557: error found hole: _ is not appropriate in the following case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ f :: [Char] f = [x | x <- ['a', 'b'], y <- (undefined:undefined:undefined:[]), z <- [1,2,3,4], r <- [True,False,True,False,True]] f' :: [Char] f' = [x | x <- ['a', 'b'], y <- (undefined:undefined:undefined:[]), z <- [1,2,3,4], r <- [True, False, True, False, True], s <- [_, _, _, _, _, _]] main :: IO () main = do print f print f' }}} When the code is compiled with the function {{{f}}} the result is the following:\\ {{{ "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb" }}} If we add in {{{f}}} the code {{{s <- [_, _, _, _, _, _]}}} to become the function {{{f'}}} and then compile the program, the following error is displayed.\\ {{{ test11.hs:5:131: error: * Found hole: _ :: t0 Where: `t0' is an ambiguous type variable * In the expression: _ In the expression: [_, _, _, _, ....] In a stmt of a list comprehension: s <- [_, _, _, _, ....] * Relevant bindings include r :: Bool (bound at test11.hs:5:86) z :: Integer (bound at test11.hs:5:70) y :: t1 (bound at test11.hs:5:29) x :: Char (bound at test11.hs:5:12) f' :: [Char] (bound at test11.hs:5:1) test11.hs:5:134: error: * Found hole: _ :: t0 Where: `t0' is an ambiguous type variable * In the expression: _ In the expression: [_, _, _, _, ....] In a stmt of a list comprehension: s <- [_, _, _, _, ....] * Relevant bindings include r :: Bool (bound at test11.hs:5:86) z :: Integer (bound at test11.hs:5:70) y :: t1 (bound at test11.hs:5:29) x :: Char (bound at test11.hs:5:12) f' :: [Char] (bound at test11.hs:5:1) test11.hs:5:137: error: * Found hole: _ :: t0 Where: `t0' is an ambiguous type variable * In the expression: _ In the expression: [_, _, _, _, ....] In a stmt of a list comprehension: s <- [_, _, _, _, ....] * Relevant bindings include r :: Bool (bound at test11.hs:5:86) z :: Integer (bound at test11.hs:5:70) y :: t1 (bound at test11.hs:5:29) x :: Char (bound at test11.hs:5:12) f' :: [Char] (bound at test11.hs:5:1) test11.hs:5:140: error: * Found hole: _ :: t0 Where: `t0' is an ambiguous type variable * In the expression: _ In the expression: [_, _, _, _, ....] In a stmt of a list comprehension: s <- [_, _, _, _, ....] * Relevant bindings include r :: Bool (bound at test11.hs:5:86) z :: Integer (bound at test11.hs:5:70) y :: t1 (bound at test11.hs:5:29) x :: Char (bound at test11.hs:5:12) f' :: [Char] (bound at test11.hs:5:1) test11.hs:5:143: error: * Found hole: _ :: t0 Where: `t0' is an ambiguous type variable * In the expression: _ In the expression: [_, _, _, _, ....] In a stmt of a list comprehension: s <- [_, _, _, _, ....] * Relevant bindings include r :: Bool (bound at test11.hs:5:86) z :: Integer (bound at test11.hs:5:70) y :: t1 (bound at test11.hs:5:29) x :: Char (bound at test11.hs:5:12) f' :: [Char] (bound at test11.hs:5:1) test11.hs:5:146: error: * Found hole: _ :: t0 Where: `t0' is an ambiguous type variable * In the expression: _ In the expression: [_, _, _, _, ....] In a stmt of a list comprehension: s <- [_, _, _, _, ....] * Relevant bindings include r :: Bool (bound at test11.hs:5:86) z :: Integer (bound at test11.hs:5:70) y :: t1 (bound at test11.hs:5:29) x :: Char (bound at test11.hs:5:12) f' :: [Char] (bound at test11.hs:5:1) }}} I think that here the wildcard pattern _ is justified and does not have to give this error and must be used as undefined.\\ So this error makes no sense here.\\ I propose to make a correction in this case. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13557 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13557: error found hole: _ is not appropriate in the following case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: Here's a simplified version {{{ f' = [True | s <- [_, _]] }}} Here `_` is not a wildcard pattern, as you say. It's an underscore in an expression, which GHC treats as a wildcard ''expression''. See [http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html #typed-holes Typed Holes] in the user manual. I think this is correct behaviour. Re-open if you disagree. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13557#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13557: error found hole: _ is not appropriate in the following case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: closed => new * resolution: invalid => Comment: Reply to simonpj.\\ Thanks.\\ I reopen this ticket in order to bring clarity to what I mean. "... The goal of typed holes is to help with writing Haskell code rather than to change the type system..." \\ I agree with Typed Holes. Here I would like to point out a matter of logical sense. {{{f' = [True | s <- [_, _]]}}} immediately raise an error. This behaviour is in conformity. Of course. But it is not necessarily correct. It will be noted that it is a single function in this context. But if {{{f'}}}is written in {{{f}}} at the end of other functions, this error has no logical sense.\\ Consider {{{undefined}}}. {{{g = [r | r <- [undefined, undefined]]}}}. the result is {{{Exception: Prelude.undefined}}}.\\ But if {{{g = [1 | r <- [undefined, undefined]]}}} the result is {{{[1,1]}}}.\\ It is as if there was no computation of {{{undefined}}}.\\ We can have the same effect if we have functions in the list as:\\ {{{h = [1 | r <- [(\x -> x*3), (\y -> y+1)]]}}}.\\ \\ Here, the function {{{f'}}} write at the end of the function {{{f}}} should play the same behaviour from a logical point of view.\\ It should also be noted that the error happens right away.\\ If the error was delayed the function {{{f'}}} would behave as with {{{undefined}}}.\\ Perhaps it is here that we must change the behavior where the error occurs?\\ In fact, it's a bit like if GHC would produce the error during the reading of {{{_}}} from the list as {{{[_, _]}}} instead of producing the error during the computation of {{{_}}}. \\ Do you understand?\\ And what do others think?\\ -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13557#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13557: error found hole: _ is not appropriate in the following case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): Hi, the code above works well if we write the flag {{{-fdefer-typed- holes}}} in the command line.\\ the result is correct and has a sense.\\ To avoid under certain circumstances a nonsense I propose that Typed Holes are not always enabled in GHC.\\ what do you think? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13557#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13557: error found hole: _ is not appropriate in the following case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm afraid I don't follow the argument in comment:2. What precisely is your objection and what are you proposing that we change? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13557#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13557: error found hole: _ is not appropriate in the following case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): Hello Ben,\\ In fact the cause does not come from Typed Holes in my opinion.\\ We need to go back in the language implementation and redefine the role of underscore {{{_}}} in an expression.\\ And hence Typed Holes will become clearer.\\ See ticket {{{#13602}}} please.\\ what do you think?\\ -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13557#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13557: error found hole: _ is not appropriate in the following case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: new => closed * resolution: => invalid Comment: See ticket {{{#13631}}}. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13557#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC