[GHC] #13557: error found hole: _ is not appropriate in the following case

[GHC]

#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