[GHC] #13602: Pattern syntax in expression context must be clarified

[GHC]

#13602: Pattern syntax in expression context must be clarified
-------------------------------------+-------------------------------------
        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 goldfire,\\

 Well! it's OK.\\
 But before, could you tell me which list of these two lists that makes
 good sense to you?\\

 {{{f1 = [-4, -4, -3, -2, 0, 3, 8]}}}\\
 {{{f2 = [-4, -4, -3, -2, 1, 3, 8]}}}\\
 And tell me why? Maybe it just seems "logical" for you?\\

 Explain your motivation :\\
 The focus here is on an incomprehensible result (that makes no sense) of
 list comprehension in certain situations which I shall try to explain
 here.\\

 Before I begin, I ask you to forget everything you've learned about the
 Haskell language. Erase everything from your memory and keep only the
 syntax of the language.\\

 1. What is a list comprehension\\
 It allow many functions on lists to be defined in simple manner. It
 employs a syntax adapted from conventional mathematics for describing
 sets. The syntax is: {{{[exp | qual1 , ... , qualn]}}}\\
 in which exp denotes an arbitrary expression, and a qualifier is either a
 boolean-valued expression or a generator. The forms for a generator we
 shall use is: {{{variable <- [list]}}}\\
 The best way of explaining what list comprehensions do is to give some
 examples.\\

 {{{
 >[x * x | x <- [1..10], even x]
 [4,16,36,64,100]
 }}}

 This list comprehension reads: the list of values x * x, where x is drawn
 from the list [1..10] and x is even.\\

 {{{
 >[3 | j <- [1..4]]
 [3,3,3,3]
 >[ x | x <- [1..3], y <- ['a','b']]
 [1,1,2,2,3,3]
 >[(\x -> True) j | j <- [(\x -> x), (\y -> y+1)]]
 [True, True]
 >[(\x -> True) j | j <- ['"', '"']]
 [True, True]
 >[(\x -> True) j | j <- ['`', '`']]
 [True, True]
 > [(\x -> True) j | j <- [_ , _]]
 [True, True]
 }}}

 2. A concrete example (chunk of Haskell code)\\
 see above.\\
 All this codes are correct codes and the compiler works fine.\\

 3. What GHC was doing with this code before today.\\
 For some reason someone raised an exception when an "underscore" was in
 an expression (inside a generator of a list expression, as far as we are
 concerned here)\\
 This is how the following code generates an error in GHC 7.6.3\\

 {{{> [(\x -> True) j | j <- [_ , _]]}}}
 pattern syntax in expression context: _\\
 And it does not make good sense.\\
 Do you "see" that "it makes no sense"?\\

 Imagine that someone removes the numeric value of the expression.\\

 {{{
 > [(\x -> True) j | j <- [1, 2]]
 }}}
 The compiler will report an error like "found numeric value in
 expression".
 This also makes no sense.\\
 Do you "see" that?\\

 Reverse the problem.
 May be that the error is justified. Then the underscore is badly used in
 the syntax and must be rewritten, I think.\\

 4. What GHC does with this code today.\\
 Today, the error "pattern syntax..." no longer exists.
 Someone created Typed Holes. And now the error is "Found Typed Holes..."
 And this also makes no sense in the example above.\\
 Reverse the problem, and rewrite the underscore syntax if justified.\\

 5. What you would like GHC to do with this code.\\
 I do not know if at this point you understood this " it makes a no
 sense".\\
 Well, avoid the compiler to provide results who makes no sense of
 course!.\\

 one more thing.\\
 Take a look in the book "Ada 2012" from Dr. John Barnes and see page 24-25
 about some behaviour of C language or in the book "Ada 2005" from the same
 author and see page 24-25 too. It's amazing. Although not speaking of the
 same thing, I think you will understand the connection between these
 things.\\

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13602#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler