Hello,
On Mon, 14 Dec 2020 18:05:07 +1100
Chris Angelico
On Mon, Dec 14, 2020 at 5:57 PM Paul Sokolovsky
wrote: But that's what the question was about, and why there was the intro! Let's please go over it again. Do you agree with the following:
a + (b + c) <=> t = b + c; a + t
?
Where "<=>" is the equivalence operator. I do hope you agree, because it's both basis for evaluation implementation and for refactoring rules, and the latter is especially important for line-oriented language like Python, where wrapping expression across lines requires explicit syntactic markers, which some people consider ugly, so there should be clear rules for splitting long expressions which don't affect there semantic.
It really depends on what you mean by "equivalent". For instance, I'm sure YOU will agree that they have the semantic difference of causing an assignment to the name 't'.
I certainly agree. But the level at which I'm trying to discuss this matter is more "abstract interpretation"'ish. For example, "+" is a binary operator, you can't calculate "a + b + c" in one step. There're 2 "+", and thus 2 steps. And an intermediate result should be "stored somewhere". In different computation models that "somewhere" would be different, e.g. in the stack machine model, intermediate result would be stored in a location on the value stack, and in the register machine model - in ("temporary") register. But from abstract interpretation PoV, all those means of storage are equivalent: a named user variable, a stack location, a temporary variable. (They have differences beyond the "storage" aspect, sure.)
Additionally, Python will evaluate a before b and c in the first example, but must evaluate b and c, add them together, and only after that evaluate a. So, no, they aren't entirely equivalent. Obviously, in many situations, the programmer will know what's functionally equivalent, but the interpreter can't.
Clarify what you mean by equivalence and I will be able to tell you whether I agree or not. (It's okay if your definition of equivalent can't actually be described in terms of actual Python code, just as long as you can explain which differences matter and which don't.)
So, let's try simple yes/no questions: Example 1: a + b + c vs a + (b + c) Question 1: Do you agree that there's a clear difference between left and right expression? Yes/no. Example 2: a.b() vs (a.b)() Question 2: Do you agree that there's a *similar* difference here as in Example 1? Yes/no. Then of course depending on the outcome of the last question, there would be further questions. Specifically: If yes: How to put a solid formal basis behind the difference in Example 2 (because so far we're just riding on the similarity with Example 1). And how to explain it to wider audience? If no: What is the explanation of such a striking distinction in treatment of Example 1 vs Example 2?
ChrisA
[] -- Best regards, Paul mailto:pmiscml@gmail.com