Add Multi-Way If proposal

[quchen]

trafficstars

Rendered version: https://github.com/quchen/rfcs/blob/multiway-if/texts/0000-multiway-if.rst

[goldfirere]

I've never liked the fact that MultiWayIf introduces a new layout context. It prevents me from writing

if |  blah
   -> baz
   |  quux
   -> wumpus

Is it possible to allow such a thing? Perhaps with a new rule that a semicolon is never added until a -> lexeme is consumed. But maybe that would confuse the grammar too much...

[quchen]

Wasn’t it the case that MultiWayIf did not introduce a layout block that led to weird bugs? If I recall correctly, nested ifs would have really awkward behaviour, resulting in the introduction of a layout block (example). What’s wrong with introducing two spaces before the -> as an alternative?

[goldfirere]

That's exactly what I do -- add two spaces. This is not horrible, though I don't love doing it. I'm just wondering if we can do better. Regardless, it would be nice to record the "weird bugs" that happened without using layout.

[quchen]

I think the Trac ticket I linked above gives quite a compelling example,

x = if | False -> if | False -> 1
                     | False -> 2
       | True -> 3

should be 3, but currently is parsed as:

{-# LANGUAGE MultiWayIf #-}
x = if | False -> if | False -> 1
                     | False -> 2
                     | True -> 3

This, to me, is far worse than having to add some indentation.

[goldfirere]

Perhaps I wasn't clear: I'm not advocating dropping the layout rule. Instead, I'm wondering about refining the layout rule to avoid putting in a semicolon until after a -> is parsed. I'm worried about the impact this would have on implementation, but I think it would be nice improvement and easy to explain to users.

[osa1]

If I understood @goldfirere's original message, I think layout rule is fine but it has a bug and requires extra indentation. I fixed it but the patch needs some reviews. See https://ghc.haskell.org/trac/ghc/ticket/10807 .