[Tutor] lists, name semantics

[Alan Gauld]

On 20/04/15 00:29, Laura Creighton wrote:

>> So in this case, the binding value is an integer, not an address.
>
> Utterly wrong.  The binding value has to be an address.

I think it depends on how you define 'binding' value.
In Python binding is the connection between a name and an object.
So in a handle type system the binding between a name and object
is the objects handle, which is usually an integer. But the
address of the object is the thing the VM uses to fetch the actual 
object based on the handle. So we have two bindings at work.
The one the user sees between the name and the object (which
is the handle) and the one the VM uses between the handle
and the actual object, which is its address at that
particular moment in time. Its the VMs job to keep track
of how that second binding changes but the users view
of binding (the handle) never changes.

>  All addresses are integers.

Usually, but not always. In segmented architectures they
are tuples of integers, and in clustered Virtual Memory
implementations they may be vectors. But in modern
machines they usually resolve to an integer.

> I have no clue what you meant by this.  Please resubmit
> and try again.  That some of the adresses are indirectly referred to
> through a list means _nothing_.

It means a huge amount to the user(programmer), especially
if he/she erroneously tries to use a handle as an address.

And of course there is a third layer of abstraction here
because often times the "address" that compiler and VM writers
think of as the physical address is nothing of the sort
its just a bit of virtual space created by the OS
which then does another binding to the real RAM chips
(or magnetic tape, or optical drive or ferrite core or
whatever technology is providing the physical storage)

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos