Matthias Blume wrote: > "Marshall" <[EMAIL PROTECTED]> writes: > > > Torben Ægidius Mogensen wrote: > >> > >> That's not true. ML has variables in the mathematical sense of > >> variables -- symbols that can be associated with different values at > >> different times. What it doesn't have is mutable variables (though it > >> can get the effect of those by having variables be immutable > >> references to mutable memory locations). > > > > While we're on the topic of terminology, here's a pet peeve of > > mine: "immutable variable." > > > > immutable = can't change > > vary-able = can change > > > > Clearly a contradiction in terms. > > No, it is not a contradiction. See the mathematical usage of the word > "variable".
I am not saying that this kind of terminology isn't common; what I'm saying is that it isn't good. And I think I gave a pretty clear and solid definition of the two words, and those definitions are decidedly contradictory. > Immutable variables can stand for different values at > different times, even without mutation involved, usually because they > are bound by some construct such as lambda. Well, that's a good point actually. Parameters are variable no matter how you look at it. I was speaking more in terms of locals. > > If you have a named value that cannot be updated, it makes > > no sense to call it "variable" since it isn't *able* to *vary.* > > Mutation is not the only way for an expression to evaluate to > different values over time. I suppose the difficulty arises from the difference between the connotation of "mutate" in a PLT context, which is support for destructive assignment, and the meaning of the word in the larger context. Anyway, I don't see how your sentence above contradicts my sentence. We do not use the term "update" to describe the process of binding values to parameters upon function invocation. (Am I wrong?) Marshall -- http://mail.python.org/mailman/listinfo/python-list
