On 2006-07-30, Gerhard Fiedler <[EMAIL PROTECTED]> wrote: > On 2006-07-30 12:45:50, Antoon Pardon wrote: > >>> [...] we'd have to use a common definition of "variable". This is a term >>> so widely used that I'm not sure there is a useful single definition of >>> it; do you know one? >> >> A name in a scope to which is attached some value/object. Now whether >> this attachment is in the form of storage or binding is IMO not >> that important. > > IMO this is not a useful definition of "variable", as it also includes what > some languages would call a "constant". This definition even includes > preprocessor macros. Once you try to come up with a definition that does > not include these, it probably gets trickier.
Sure it is usefull. It may be not 100% formally correct, but often things that are not 100% formally correct can be better in bringing an idea accross. >>> [ ... ] >> >> That depends on what you call the identity. If I had to translate this >> into C++ it would be something like: >> >> int *a, *b; >> >> a = MakeInt(3); >> b = a; >> b = MakeInt(4); > > Yup. But in C/C++ speak, it's more common to call a and b "pointers" rather > than "variables". Well in a case like: int a, b; You may call a and b "ints" rather than variables, that doesn't stop them from being variables. > Of course they are also sometimes called "pointer > variables", but not usually "variables". It's of course not technically > wrong to call the variables, but it's probably rare. And for a reason. Well I don't know about who you talk with, but when I was still using C and other like languages on a daily basis me and my collegues had no problem using the word variable, just because the type of the variable happened to a pointer. AFAIK, the C language reference doesn't make an exception for calling something a variable, based on the type (pointer or not) of the variable. > [ ... ] > Whether Python variables are in fact "variables" probably depends mostly on > your definition of "variable", and that's IMO a tough one -- a definition > of "variable" that includes all those language elements that various > languages call "variables", and nothing else (that's the tough part). > Whether that definition exists, and whether it includes Python "variables", > remains to be seen :) Since Python variables seem to behave essentially the same way as Lisp and Smalltalk variables and as far as I know "variable" is the accepted term in those languages for what we are talking about, I don't see how you can have a definition that includes those languages but will not include python. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list