Marko Rauhamaa writes: > Jussi Piitulainen writes: > >> In point d, McCarthy refers to variables as variables; I'm sure this >> would go back to Church and 1940's at least, so I expect they used >> this word already back then. But the ability to store new content to >> the data structure that associates variables with stuff must be >> newer. I think it was new with LISP. > > As far as the words "variable" and "binding" go, they are present in > lambda calculus (1929 and on):
So it's more than ten years earlier than I thought. Old enough, anyway. Strictly speaking, that a Wikipedia article uses the words "variable" and "binding" to discuss lambda calculi today is not a proof that Church used those words in his time. I'm inclined to believe he did. (Our CS department had a copy of Church's book. It smelled funny.) A point is that McCarthy knew about lambda calculus. That's where the name "lambda" for the binding operator comes from, together with "variable" and "binding" and the correct scoping rules that other people worked out quite a bit later. >> I don't know if assignment was originally called assignment, or >> whether the association of names with stuff was originally called >> binding, but this terminology is old enough that I've known binding >> and assignment of variables by these names for as long as I can >> remember, with more or less the semantics that Python now >> uses. "Rebinding" I've not known elsewhere. > > I think "binding" is too fancy a word to be used with conventional > programming languages like Python. If your programming language has an > assignment statement, "binding" is even nonsensical. The term has more than fifty years of history in languages that have not only an assignment statement but also mutable things. It's needed to speak of where and when in a program the occurrences of an identifier have what meaning. A statement like x = 31 does not affect every x even in a Python program, only those that are bound in the same namespace. In Scheme, a variable is bound to a location where its value is stored. A variable reference evaluates to that stored value. In Python, one chooses to say that a mumble is bound to an object, but then there is a namespace that also serves as a store where one can put a new object, like one can put a new object in a Python dictionary, and then the mumble becomes bound to that object instead. These are different ways to talk about the same thing. (The Scheme way in a sense "explains" mutable store in terms of mathematical functions where the Python way takes it for granted, I think). No nonsense. > Consider: > > def f(x): > x += 1 > return 2 * x > > Now we would have this reduction: > > f(7) > => > 7 += 1; return 2 * 7 > > because "x" would be bound to "7" everywhere in the function body. You know, people have developed further ways to talk about these things precisely because substitution semantics is inadequate for what they wanted to talk about. See references in that Wikipedia article (Felleisen might be to the point. The field is called denotational semantics.) The description, in the language reference (or is it the library reference), of how Python function calls are evaluated can be seen as an example. First the actual arguments and possibly some defaults are put in fresh locations, then the formal parameters are bound to these in an order that is a bit complicated because of keyword parameters and such, but nevertheless *bound* *then*. Not substituted to the program text - who would even think that? And then the evaluation of the occurrences of the parameters in the code of the function goes through *these* bindings rather than any other bindings that might be in effect elsewhere in the program, including any pending calls of the same function. -- https://mail.python.org/mailman/listinfo/python-list
