<Perelandric>
So it seems like in the `go()` method, 'this' and 'that' should be referencing the same object...
<Perelandric>
because `foo1 = recover Foo end` looks like it should be returning the previous value of `foo1`
<Perelandric>
which is the same as the receiver.
<Perelandric>
Yet they'
<Perelandric>
Yet they're different objects in the `go()` method.
<Perelandric>
Why?
<Perelandric>
Oh... it's reversed. The receiver is the new object, and the argument position passes the old one.
felixgallo has joined #ponylang
<Perelandric>
Sylvan mentioned that the only way to resolve the original issue would be to not allow expressions in the argument position.
<Perelandric>
...but couldn't pony just disallow mutating the variable that is the receiver of the call?
hibnico has quit [Quit: hibnico]
<Perelandric>
Maybe it's just me, but that behavior just seems terribly confusing.
<jemc>
Perelandric: disallowing that wouldn't be as simple as it sounds
<jemc>
what if the receiver was a method call that ultimately returns a certain field, and the argument expression calls a method that changes the value of that field internally
<jemc>
that the receiver is going to be changed to something else before calling is something the compiler can't really know without digging into both of those methods
<Perelandric>
Yes, I see what you're getting at.
<Perelandric>
So the order of evaluation is...
<Perelandric>
1) all arguments (including those of chained calls) evaluated left-to-right
<Perelandric>
2) the receiver, which may be an implicit `this`
<Perelandric>
3) the actual calls evaluated left-to-right
TwoNotes has left #ponylang [#ponylang]
<jemc>
seems right - probably the easiest way to test would be something like: `(Debug("foo"); foo).go((Debug("bar"); bar), (Debug("baz"); baz))`
<jemc>
(or move those parenthesized statements to methods for more clarity, perhaps)
<Perelandric>
Yes, it gives `"bar" "baz" "foo"` as we would seem to expect.
<Perelandric>
Also works with a nested receiver and call in one of the argument positions.
<Perelandric>
Sort of a depth-first situation.
<Perelandric>
So I guess it really isn't all that confusing... just a little unfamiliar.
<Perelandric>
Thanks for the clarifications. Very helpful!
<jemc>
now we just have to figure out how/where to document it...
<jemc>
"depth first" is a nice way to think about it
<Perelandric>
It also seems that the variables in argument position are resolved to their reference, and not their value.
<Perelandric>
This code: `var f = "foo"; foo.go(f).go(f = "bar")` passes "bar" then "foo" instead of "foo" then "foo"