[GHC] #11706: Increase precedence of statements (if-then-else, case-of, do)

[GHC]

#11706: Increase precedence of statements (if-then-else, case-of, do)
-------------------------------------+-------------------------------------
        Reporter:  YoYoYonnY         |                Owner:
            Type:  feature request   |               Status:  infoneeded
        Priority:  lowest            |            Milestone:  ⊥
       Component:  Compiler          |              Version:
  (Parser)                           |
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by bgamari):

 * status:  new => infoneeded


Comment:

 Thanks for writing this up.

 Indeed you are not the first one to propose some variant on this idea
 (see, e.g., #10843). Not so long ago there was a rather lengthy discussion
 on this matter, which I summarized in ticket:10843#comment:12.

 I'll admit that don't believe that too-many-dollar-signs is the greatest
 of our problems and am skeptical that this sort of pragma would pull its
 weight. That being said, I'm happy to help you work through the details of
 this proposal.

 To begin, I think we should clear up a few nits,

  * the definition of "statement" being used here contradicts that defined
 by the Report (which defines it as being a monadic action in a `do`
 block). The `if` and `case` constructs are merely parts of the expression
 grammar.
  * several of your examples use `=` to delimit the sides of a case branch
 where you likely meant `->`.
  * what about `let` expressions? It seems rather odd that they are
 excluded here.
  * lambdas are a bit different from the other constructs here, but still
 worth thinking about
  * how does the binding of these expressions compare with that of infix
 functions? For instance, what does `(+1) <$> do return 42` mean?

 Our grammar is already very complex; any proposal to add further
 complexity needs to be carefully specified. If you would like to see this
 feature (and think that your proposal differs significantly from that of
 #10843) could you start a Wiki page describing precisely how your proposed
 parsing scheme differs from that described in Report? Also, keep in mind
 that this may interact with other syntactic extensions; be sure to
 consider how these interactions may play out.

 I would guess that you want to start by looking at
 [[https://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17800010.3|layout]]
 section.

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