[fix] separation between isTemp from the compiler/AST pov

[hogoww]

isTemp from the compiler pov == isArgOrTemp (because the VM treats them the same way)
We now have 2 different perspective for isTemp.
Compiler tests passing, we'll see with the CI for the others.

[hogoww]

failures are unrelated, see 6023

[dionisiydk]

Maybe we can keep isTemp for all kind of temps. But in addition we can add isArgument.

[hogoww]

#isArgument is already there (AST point of view)
also, #isArg is there (compiler POV)

Also, isTemp from the compiler POV is arg + temp,
whereas from an AST point of view it's only Temporary nodes.

[dionisiydk]

Oh, It looks really messy.
We should not have different API depending on POV.

The binding object is always there whatever we do with semantic analysis.
So can we just keep binding based version and remove the rest? Why it is bad idea?

[hogoww]

I assume it's because they both got developed concurrently, so some stuff got intertwined.
Technically, RBVariableNode >> isTemp/isArg & co are extention methods from the compiler, but they are still used as regular methods by users (I'm part of them)

"The binding object is always there whatever we do with semantic analysis."
This is true when you take a compiled method, this is might not be when you have a tool that is modifying the AST (which I do), without (at least directly) recompiling it.
For example I take do:
m := aCompiledMethod ast.
m firstModifyStep.
m secondModifyStep.
m compile. "maybe, not always"

And when I move a node to be temporary from argument for example, I loose the binding (which I don't care about). This prevents me to use those selectors without custom overrides.

[dionisiydk]

See my comment in another PR on idea to rely only on bindings. I think it will allow to simplify such operations.

And when I move a node to be temporary from argument for example, I loose the binding (which I don't care about). This prevents me to use those selectors without custom overrides.

Here it could be something like:

RBVariableNode>>beTempVariable
      binding := OCTempVariable inScope: binding scope.

I see that now #parseTree does not add any binding to variable nodes. But we can have something as default (OCUnresolvedVariable).

Now I also wonder why we use a #binding name here instead of #variable (all OC hierarchy is about variables).
It would be much simpler to have RBVariableNode>>variable.

[dionisiydk]

But I understand now we have what we have. So what I wrote is just ideas