Possible future suggestion: Add a `InlineStatements` language pragma which puts implicit parenthesis around `if-then-else`, `case-of` and `do` blocks,

See: http://pastebin.com/T7L6GyBu (Permanent pastebin)
for a example program.

On Mon, Feb 29, 2016 at 1:22 AM, Thomas Tuegel <ttuegel@gmail.com> wrote:
On Sun, Feb 28, 2016 at 5:20 PM, Jonne Ransijn <yoyoyonny@gmail.com> wrote:
> Dear Haskell-Cafe mailing list people (?)
> I've been writing parenthesis around do blocks since forever now, but I
> don't get why they are necessary. I can't seem to come up with a program
> where they are necessary. Am I missing something or are parenthesis around
> do blocks nececairy for no reason? Since parsing 'do' blocks as if they have
> parenthesis around them doesn't seem to break any code, why not do so?
>
>     when (doBlocksNeedParenthesis) do putStrLn "This code is invalid."
>
>     when (doBlocksNeedParenthesis) $ do putStrLn "This code is valid."
>
>     when (doBlocksHaveInvisibleParenthesis) do putStrLn "These are equal v"
>
>     when (doBlocksHaveInvisibleParenthesis) (do putStrLn "These are equal
> ^")

This syntax can be ambiguous; consider:

> (flip when) do putStrLn "Where do the parentheses go?" True

I admit this is contrived; we could choose to put parentheses around a
do-block only if it is the terminal argument. There is a case that is
completely unambiguous:

> (flip when) do { putStrLn "Braces might as well be parentheses." } True

Certainly, I don't see why this shouldn't parse.

Regards,
Tom