How do method-calls interact with operator precedence? - ruby

Question

I am curious about how method calls relate to operator precedence. In irb, I see this:
var = puts(5)
5
=> nil
var
=> nil
This implies that the call to puts has higher precedence than the assignment operator, since nil (the return value of puts(5)) is assigned to var, rather than the method call itself. Because nil is assigned to var (as we can see on line 4), I would guess that puts(5) was called before the assignment operator.
In this Stackoverflow thread, everybody agrees that method-calls have lower precedence than every operator.
However this website lists the . as an operator for method-calls, and says that it is the highest-precedence operator.
If this second website is indeed accurate, I'm unsure about whether there is an implicit . operator when you call a method on main (and therefore about whether . being a high-precedence operator is sufficient to explain the irb session above).
In general, I'm curious about the order in which Ruby does things when it encounters a line of code, so if you know of any resources that explain that in an accessible way I would be interested in reading them.
EDIT: thanks for answers so far. Maybe I wasn't clear enough about my basic questions, which are theoretical not practical (so are arguably 'overthinking', depending on how much you like to think):
is . technically an operator, or technically not an operator?
is there a . somewhere behind the scenes every time you call a method?
are operators the basic way that Ruby decides in what order it will evaluate a line of code, or are there factors other than operators and their precedence/associativity/arity?
Thanks

Answer 1

You're overthinking this. Your expression is basically this: x = something. So, right-hand side must be evaluated first, then the assignment can be done.

Answer 2

Here is how to print AST
2.6.3 :008 > RubyVM::AbstractSyntaxTree.parse('x = puts(5)')
=> #<RubyVM::AbstractSyntaxTree::Node:SCOPE#1:0-1:11>
2.6.3 :009 > pp _
(SCOPE#1:0-1:11
tbl: [:x]
args: nil
body:
(LASGN#1:0-1:11 :x
(FCALL#1:4-1:11 :puts (ARRAY#1:9-1:10 (LIT#1:9-1:10 5) nil))))
=> #<RubyVM::AbstractSyntaxTree::Node:SCOPE#1:0-1:11>
I'm using ruby 2.6. This way is possible to solve any parsing doubt. For this case is little obvious as other answers said if you have x = expr, then expr need to be evaluated first since we're talking about a strict language, for lazy languages you will only need to evaluate expr when x is evaluated, but this is another topic

Answer 3

I'm guessing you come from a JavaScript or similar background. Where the following is possible:
function puts(...args) { args.forEach(arg => console.log(arg)); }
var x;
(x = puts)(5);
puts(x);
However in JavaScript calling puts without () will return the whole function. Which allows easy function assignment. However in Ruby calling puts without () will still call the method. Making parentheses optional. See the Calling Methods documentation.
In Ruby (x = puts)(5) would result in a syntax error. You can achieve the same by doing the following:
(x = method(:puts)).call(5)
# here parentheses are still required since
x = method(:puts).call(5)
# will still assign the result of the puts call to x
The first link you provided talking about operators having a higher precedence than method calls is talking about method arguments.
puts 5 + 5
# can be seen as
(puts 5) + 5
# or
puts (5 + 5)
In this case 10 is printed since the operators have higher precedence than the method call itself. This also works for the = operator, but when used as argument.
puts x = 5
Will print 5, return nil and have 5 assigned to x. When using x = puts 5, x can't be assigned without evaluating puts 5 so that is what happens first. Precedence only comes into play if the same code could be executed in multiple ways.
Calling methods with parentheses never yields the above issue.
puts(5 + 5)
# or
puts(5) + 5
Both speak for themself. Although the latter will raise a NoMethodError.