Precedence inside a function call

Question

Using the defined-or operator ( // ) in a function call produces the result I'd expect:

say( 'nan'.Int // 42); # OUTPUT: «42»

However, using the lower-precedence orelse operator instead throws an error:

say( 'nan'.Int orelse 42); 
# OUTPUT: «Error: Unable to parse expression in argument list; 
#                 couldn't find final ')' 
#                 (corresponding starter was at line 1)»

What am I missing about how precedence works?

(Or is the error a bug and I'm just overthinking this?)

Answer 1

I'd say, it's a grammar bug, as

say ("nan".Int orelse 42);  # 42

works.

Answer 2

TL;DR My super useful naanswer (not-an-answer / non-authoritative answer / food for thought) is it might be a bug or it might not. :)

---

Other examples:

say(42 and 42);
say(42 ==> 99);

yield the same error.

What am I missing about how precedence works?

Perhaps nothing. Perhaps it will be desirable and possible to fix the grammar so these function-call-arg-list-signifying parens determine precedence just like plain expression parens do.

If so, perhaps fixing it would best wait, or perhaps realistically must wait, until when or after RakuAST lands (6.e?). Or perhaps even later, lf/when grammar cleanup/slangs lands (6.f?).

---

Or perhaps it's going to always stay as it is for reasons such as good usability (despite the initial "huh?") and/or expediency and/or single-pass parsing and/or whatever.

---

I've dug a little to see if I could find relevant commentary. Here are some (juicy?) bits:

the OPP is a bit more complex than a standard binary-operator OPP

(from a comment on #perl6)

If you scroll backwards from Larry's comment you'll see he said this in the context of Raku's extraordinary seamless parsing (no delimiters introduced) in a single pass of nested sub-languages that each can have arbitrary grammars.

(Btw, one thought I had: did std parse say(42 and 42) fine? I'm not sure if there's a running std anywhere these days.)

While we do have complete control of stock Raku, I'm not convinced there's anything compelling about bending over backwards to fix every wrinkle of this sort (foo(... op ...) in this case) when the general case (..... where the middle ... inside the outer pair of .s has arbitrary syntax) means we'll be hitting limits in how "perfect" it can all be when there's a huge amount of anarchic language / syntax mixing going on in userland/module space, as I anticipate will emerge in years to come.

So, imo, if it's reasonably easy to fix, without unduly cramping or burdening user slang freedom, great. If not, I think the current situation is fair enough (though perhaps it'll be desirable, viable and reasonable to improve the error message).

---

Perhaps consider the foregoing in combination with:

Raku borrows many concepts from human language ...

(from the doc)

in combination with:

? Self-clocking code produces better syntax error messages

(from Seeing Wrong Right)

in combination with:

Break that clock and your error messages will turn to mush

(from a mailing list comment)

But then again:

Please don't assume that rakudo's idiosyncracies and design fossils are canonical.

Answer 3

Do you mean this, maybe...?

> say ( NaN.Int orelse 42 )
42

since

> say( NaN.Int orelse 42 )
===SORRY!=== Error while compiling:
Unable to parse expression in argument list; couldn't find final ')' (corresponding starter was at line 1)
------> say( '42'.Int? orelse 42 )
    expecting any of:
        infix
        infix stopper

I would tend to agree with @lizmat that there is a grammar bug in the compiler.