#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