Addressing the last element of a list

[Antoon Pardon]

Op 2005-11-14, Mike Meyer schreef <mwm at mired.org>:
> Antoon Pardon <apardon at forel.vub.ac.be> writes:
>> Op 2005-11-10, Mike Meyer schreef <mwm at mired.org>:
>>> [Context recovered from top posting.]
>>> "bonono at gmail.com" <bonono at gmail.com> writes:
>>>> Daniel Crespo wrote:
>>>>> Well, I hope that newcomers to Python don't confuse himselves :)
>>>> This mutable/immutable object and name/variable is confusing.
>>> Only if you have to overcome a conviction that variables behave in a
>>> different way. If you've never seen them behave another way, or have
>>> already gotten used to this model from another language (it dates back
>>> to the 60s, if not the late 50s), then it's no problem. I'm sure the
>>> problem exists in the opposite direction, except that few people
>>> travel that route.
>>> Most OO languages do the name/variable thing, but some of the popular
>>> ones aren't consistent about it, giving some types "special" status,
>>> so that sometimes "a = b" causes b to be copied onto a, and sometimes
>>> it causes a to become a pointer to b. I find a consistent approach is
>>> preferable.
>> But what about a consistent approach, that allows choice.
>
> It's been done in other languages. But it requires more care than one
> would think.

That is possible.

>> Like having an assignment operator (let use @= for it) next to a
>> (re)bind operator.
>>
>> We could then have something like the following.
>>
>> a = 5
>> b = a
>> a @= 7
>> b ==> would result in 7.
>
> You've just overwritten the object referred to by the token "5" in the
> source code with the value 7, so you get:
>
> print 5
> 7
>
> Not exactly a desirable outcome, but some language implementations
> have allowed this kind of thing in the past. You either have to make
> all objects mutable, or disallow assignment to immutable objects,
> which sort of defeats the purpose.

You have a valid point, but I think a different approach is possible.
Don't make the distinction between mutable and immutable types but
between mutable and immutable objects. So an int wouldn't be an
immutable type, but 5 would be an immutable object.

So the code above I gave would throw an exception, but the following
might work.

a @= 5
b = a
b @= 7
a ==> would result in 7.

> Another approach is to have a special object type if you want to allow
> assignment to the object it refers to. That's what Python does now, it
> just doesn't have a syntax just to support that. If it did, your
> example might look like:
>
> a := 5
> b = @a
> a := 7
> @b ==> would result in 7

Could it also work the other way? By somehow manipulating b change a?

-- 
Antoon Pardon