Nested function scope problem

[Antoon Pardon]

On 2006-07-28, Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:
> On 27 Jul 2006 18:09:37 GMT, Antoon Pardon <apardon at forel.vub.ac.be>
> declaimed the following in comp.lang.python:
>
>> 
>> It is irrelevant because the word "variable" is used in a lot of
>> different languages. A lot of them with behaviour closer to python
>> than to C. The difference between C variables and Python bindings
>> is only relevant if it can give you an argument for why we shouldn't
>> use "variable" when discussing python.
>>
> 	Typically, "variable" implies a data storage location that can take
> on different values. Emphasis on "location" -- the name is fixed to a
> memory location whose contents can be varied.

That is not true. It may be the case in a number of languages but
my experience with lisp and smalltalk, though rather limited,
says that no such memory location is implied with the word "variable"
in those languages and AFAIK they don't have a problem with the
word "variable" either.

> In Python, the closest
> would be a mutable object.

> 	Python names are not fixed to a location.

Neither are smalltalk and lisp variables. Neither are C-variables
local to functions.

> One can actually delete
> the name at runtime and NOT have the object deleted.

How important is this? Should we remove the del statement from
python would it make such a big difference that you would then
think the term "variable" was more appropiate? 

>> I'll be more clearer: If someone wants to extend python with
>> a kind of static typing, where you could limit names binding only
>> to objects of a certain number of classes, it wouldn't essentially
>> change what could be done with names in python, but the names would now
>> hold type information too. So whether a name carries type information
>> or not, has little relevance to whether the term "variable" is appropiate
>> or not.
>>
> 	And what happens if you do a "del name1" followed by some binding to
> name1? Will the restriction of name1 to a limited class of objects be an
> executable statement (a la def)? If so, how would you handle:
>
> dec name1(object1)
>
> def x():
> 	# do something using global scoped name1
> 	#expecting an object1 inference?
>
> del name1
> dec name1(object2)
>
> x()	#invoke x when name1 has object2 aspects
>
> 	If you forbid the "del name1", you have just violated your wouldn't
> essentially change" statement. If you permit del and an executable
> typing statement, you've just lost your "static typing"

1) I think that is unimportant. Maybe "static typing" was not the right
wording. One argument against the use of the term "variable" in python
was that unlike C, there was no type information associated with a name.
My hypothetical extention to Python would be a very python-like language
where type information was associated with a name. Now if you want to
call this specific type extention, static or something else is IMO
not important. The point is that what one can do with variable is
hardly affected by this characteristic of names being associated
with type information or not.

Beside, Lisp and smalltalk variables don't have type information
associated with names either.

-- 
Antoon Pardon