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

GHC ghc-devs at haskell.org
Sat Apr 22 14:05:13 UTC 2017


#13602: Pattern syntax in expression context must be clarified
-------------------------------------+-------------------------------------
           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:
-------------------------------------+-------------------------------------
 To simonpj\\
 see tickets {{{#13557}}} and {{{#13579}}}\\


 Typed Holes does not exist if we compile with GHC version 7.6.3.
 Instead of "error found holes" it indicates "pattern syntax in expression
 context: _".\\
 I then understood that to improve Typed Holes it was first necessary to
 remove the ambiguity of the error in GHC 7.6.3 about pattern syntax in
 expression.\\

 {{{let f = [True | x <- [_, _]]}}} raise the error
 {{{pattern syntax in expression context: _}}}\\
 But as Typed Holes, this error has no sense here.\\

 {{{let f' = [_ | x <- [1,2]]}}}will give a result like
 {{{"__"}}} And this calculation also makes sense if one refers to the rule
 of inference, as the function
 {{{f}}}
 .\\
 \\
 The compiler should not impose its way.\\
 The programmer must be the master of his code.
 Here the rule of inference seems flouted.\\

 Good sense or reason is argued to be the same in all people, yet
 differences in opinion are not due to differences in intelligence but to
 the fact that we use different approaches and consider different things.\\

 Here you will find some ideas:\\
 Instead of "underscore _" as "pattern syntax" we could use a new type
 called "indefinite" in expression.\\
 Any calculation with "indefinite" will result in "indefinite".\\
 In another calculation, the "indefinite" type could have a type defined
 according to a directive applied to the compiler.\\
 example:\\
 indefinite :: Int\\
 f = [1,2,3,indefinite,5,6]\\

 I took a look at ticket {{{#9497}}} and find it very interesting.\\

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


More information about the ghc-tickets mailing list