Increase precedence of lexps (if-then-else, case-of, do, lambda and let-in)

Intro

For readability, the intro is now available here.

How it works

• Implicit parenthesis will be put around all lexps, according to the following rules:

1. Parenthesis will be opened at the start of the lexp.
2. Parenthesis will be closed at the end of the lexp. The end of the lexp is determined by
3. The curly brackets around the lexp (If possible), or;
4. The indentation of the lexp

Basically, these are the rules Haskell already uses.

As for the Context-Free Syntax found at https://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17800010.3|layout, lexp would have to be moved up, dropped out of infixexp, and added into exp (As well as a few other places in aexp and guard)

Motivation

As for my personal motivation, I think that, with all the other syntactic extensions already implemented, this feature is definitly missing.

As Richard Eisenberg already pointed out (See this comment); combining lexp with aexp would make the Haskell syntax more consistent.

bgamari listed above argument and quite a few other pros and cons here.

A few arguments not listed there:

• If the Haskell community ever decides to implement this feature in the main language, we will already be prepared.
• Similairly, if this feature ever gives problems or adds new interesting possibilities to the language, we will be prepared.
• Yet another syntactical extension means yet another thing to look out for;
• However, this also means people will become more aware of LANGUAGE pragmas.

Naming

Here follow a few suggestions for the name of this extension:

• InlineStatements
• InfixStatements
• ParenthesizedStatements
• IncreasedStatementPrecedence
• StatementsWithoutParenthesis

Here are some more, taken from over here.

• ArgumentBlock
• ArgumentDo

Examples

Examples can now be found here.

Resources

[1] Cheesy intro: http://pastebin.com/8Fsh7pAE

[2] Original examples: http://pastebin.com/6kLQvKs9

[3] Pros and Cons: https://ghc.haskell.org/trac/ghc/ticket/10843#comment:12

[4] ArgumentBlock proposal: https://mail.haskell.org/pipermail/haskell-cafe/2015-September/121217.html

mentioned in issue #10843 (closed)

changed milestone to %⊥

changed weight to 0

added Tfeature request Trac import parser labels

Thanks for writing this up.

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

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 (closed)) 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 layout section.

changed title from Increase precedence of statements (if-then-else, case-of, do) to Increase precedence of lexps (if-then-else, case-of, do, lambda and let-in)

changed the description

Thanks for linking that ticket, I skimmed over the list of feature requests, but could not find any other requests asking for increased lexp precedence or similair. I suppose I underestimated the priority of this feature request.

The typos in the ticket should now be fixed. The ticket is also simplified, the old code examples have been moved to Pastebin here (As a permament paste) for readability, and the cheesy intro has been moved to a separate Pastebin too, here, to save a few clicks. I'll work on making more clean and general examples.

I have to say that I agree; the proposal is mostly useless, one or two characters saved won't make a big difference. However, with other similair pragmas already implemented (UnicodeSyntax, RecordWildCards and TupleSections to name a few) I think it is reasonable to implement this feature somewhere in the future, be it with low priority. I think it is fair to refer to if-then-else, case-of, do, lambda and let-in as lexp, following https://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17800010.3|layout, unless of course someone can think of a better term. The set of lexps could of course also easily be extended with lambda-case and mdo (If this is not already the case).

I have added lambda and let-in to the title, as these are part of the proposal. I've also added lambda to the examples, aswell as lambda-case, mdo and infix ones.

I will leave the creation of a Wiki up to someone with more experience with the GHC Parser, although I might look into it myself sometime soon. As to if this ticket is diferentiatable from #10843, I would say yes, this ticket is more general, however I would strongly recommend merging this ticket with #10843, if that is in any way possible.

changed the description

I believe this has been implemented as the BlockArguments extension.

added Plow label