#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