Hello,
On Mon, 14 Dec 2020 18:05:07 +1100
Chris Angelico <ros...@gmail.com> wrote:
> On Mon, Dec 14, 2020 at 5:57 PM Paul Sokolovsky <pmis...@gmail.com>
> 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:pmis...@gmail.com
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/IKF27IGMHFCH7OBE4XJX54ZSEKGQ347U/
Code of Conduct: http://python.org/psf/codeofconduct/
