coding style - where to declare variables

[Steven D'Aprano]

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