Operator priority: binary ops vs. 'if' expressions

[dermagen]

Hi! I am a bit confused by the fact that

let x = 2 * if (false) 3 else 4 + 5
print(x)

compiles (in the Try window) and prints 18
... which means that somehow + binds tighter than *

Can this be explained in terms of operator priorities or BNF-like grammar?
Thanks!

[ospencer]

Hey @dermagen. You can find Grain's general operator precedence here: https://github.com/grain-lang/grain/blob/main/docs/contributor/operator_precedence.md

There'll be a page about this on the website as well, but it hasn't made it there just yet. It doesn't contain any information about how this interacts with if expressions, though.

else attempts to parse as much as it can as an expression, so it captures the entire expression 4 + 5. You can look at this in Grain's grammar if you'd like: https://github.com/grain-lang/grain/blob/main/compiler/src/parsing/parser.mly#L502

I'm not sure what you mean when you say traditional operator grammars. In most languages, if is a statement rather than an expression, so like you mentioned, it's a syntax error. AFAIK, languages with if expressions with a similar syntax parse this the same way Grain does. For fun, I checked OCaml and Elm (since the syntax for this is similar enough) and they both produce 18. Rust requires braces around the then and else values which prevents the ambiguity, and Ruby requires the end keyword which, at least in this case, prevents the ambiguity.

I think the important thing to consider here is that the multiplication doesn't have anything to do with the rest of the line and isn't the deciding factor in how the addition interacts with the if, i.e. removing the multiplication doesn't affect how the rest of the line is parsed.

[dermagen]

I understand that implementing it like that is a choice that can be made. It's just that, in my opinion, this choice produces not just code that is ambiguous, but a code that is ambiguous in the wrong way, that is, going against expectations of some people. The argument in the last paragraph can be applied to any operator combination, e.g. x * foo(y) + z -- where the claim 'multiplication does not have anything to do with the rest of the line [and] is not a deciding factor in how addition interacts with foo(y)' is obviously wrong. Requiring if expression to be parenthesized if used as argument in a binary expression would solve this problem. Just a thought -- thanks.

[dermagen]

BTW, I stepped on this problem trying to write PEG grammar for Grain, based on parser.mly. This is the only problem I have encountered in the process -- the rest is more or less straightforward. At the very least, I think it would be nice for automated formatter to parenthesize ifs in binary op context to remove the ambiguity.