Nested function scope problem

[Antoon Pardon]

On 2006-07-30, Gerhard Fiedler <gelists at gmail.com> 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