On Mon, 23 Jul 2018 20:24:30 +1200, Gregory Ewing wrote: > Steven D'Aprano wrote: >> So let me see if I understand your argument... >> >> - we should stop using the term "binding", because it means >> nothing different from assignment; >> - binding (a.k.a. "assignment") comes from lambda calculus; >> - which has no assignment (a.k.a. "binding"). > > No, that's not what Marko is saying at all. He's pointing out that the > term "binding" means something completely different in lambda calculus.
Well done in reading Marko's intent. Unfortunately, I'm not as good as inferring meaning as you seem to be, consequently I had to judge by what he wrote, not what he meant. When a writer fails to communicate their intent, that's usually the failure of the writer, not the reader. We aren't mind-readers and writers should not blame the reader when they fail to communicate their intended meaning. > The terms "bound variable" and "free variable" in lambda calculus mean > what in Python we would call a "local variable" vs. a "non-local > variable". Actually, no, they are called "bound variable" and "free variable" in Python too. https://docs.python.org/3/reference/executionmodel.html See also: http://effbot.org/zone/closure.htm Alas, I don't think Fredrik Lundh got it *quite* right. I think that globals (and builtins) in Python are "open free variables", as opposed to nonlocals which are closed. And sadly, the Python glossary currently doesn't define free variables nor bound variables, or even name binding. > They have nothing to do with assignment at all. That's not quite correct either. Lambda calculus has the concept of a binding operator, which is effectively an assignment operator: it takes a variable and a value and binds the value to the variable, changing a free variable to a bound variable. In other words, it assigns the value to the variable, just like assignment does. In Python terms, = is a binary binding operator: it takes a left hand operand, the variable (a name, for the sake of simplicity) and a right hand operand (a value) and binds the value to the name. > Marko is asking us to stop using the word "binding" to refer to > assignment because of the potential confusion with this other meaning. Marko has some idiosyncratic beliefs about Python (and apparently other languages as well) that are difficult to justify. Especially in this case. Anyone who understands lambda calculus is unlikely to be confused by Python using the same terms to mean something *almost identical* to what they mean in lambda calculus. (The only difference I can see is that lambda calculus treats variables as abstract mathematical entities, while Python and other programming languages vivify them and give them a concrete implementation.) If one in ten thousand programmers are even aware of the existence of lambda calculus, I would be surprised. To give up using perfectly good, accurate terminology in favour of worse, less accurate terminology in order to avoid unlikely and transient confusion among a minuscule subset of programmers seems a poor tradeoff to me. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list