why cannot assign to function call

[John O'Hagan]

On Tue, 30th Dec 2008, Aaron Brady wrote:

>Accepting that, I'll adopt the terms John proposed, 'change' vs.
>'exchange', the former when the material configuration changes, the
>latter when the communication axioms change.
>
>b= [2, 3]
>b= [3, 4]
>
>'b' has exchanged.  (Somewhat ungrammatical.)
>
>b= [2, 3]
>b.append( 4 )
>
>'b' has changed.
>
>According to this, when you replace every floorboard on a porch, one
>at a time, it's still the same porch-- it's changed, it's different,
>and it's the same.  However, if you haul off the porch and put a new
>one in its place, it's not.  ('porch[:]=' vs. 'porch='.)  You can't
>just look at the initial and final configurations of matter to
>determine so.  Therefore, 'id' is an informal function.

This analogy describes the "ontological minefield" I was referring to in a 
previous post in this thread (which has expired in my mail reader, so my 
apologies if the threading goes awry): In what sense is a porch (or list, or 
string) the same if all (or even some of) its parts have been exchanged? 

I think the answer is something to do with the abstraction, the "container", 
the instance of the class. Would it be fair to say that perhaps there are no 
truly mutable objects, only immutable containers whose contents (also 
immutable objects themselves) may be exchanged? Or to pose the question 
another way, are objects only mutable insofar as they are composite?

As you argue above, the planks are not the porch; I would add that it's your 
_decision_ to build (or tear down) a porch which makes it _that_  particular
porch (or not). 

As you imply above (I think), you have to keep looking (or someone does, 
presumably the interpreter) to know whether an object is the same as or just 
equal to another (which starts to sound spookily like the role of "the 
observer" in phenomenology or quantum physics). Whether this means that id() 
is "informal" or not, I'll leave to others better informed than I.

Regards,

John