why cannot assign to function call

[Aaron Brady]

On Dec 30, 8:21 am, John O'Hagan <m... at johnohagan.com> wrote:
> On Tue, 30 Dec 2008, Aaron Brady wrote:
>
> [...]
>
> > On a technicality, to avert a flaming, "change the value of 'b'" is an
> > ambiguous phrase. There are two interpretations of "change what 'b'
> > refers to" and "change what 'b' refers to". Even in spoken language,
> > I don't think that emphasis can resolve them either.
>
> > One means, 'make a change in the world, in the actual configuration of
> > such and such actual matter.' The other means, 'update the axioms the
> > speaker is using to communicate to the listeners. (Such and such will
> > no longer refer to such and such; it will refer to such and such;
> > accept this and reject that.)' To make an observation, reference is a
> > purely linguistic phenomenon.
>
> > I, for one, am at a loss for how to disambiguate it. I'm open to
> > suggestions.
>
> I think you've already done so quite clearly. But I suspect the ambiguity
> centres on the word "change" - in the first interpretation it means "alter"
> (the object in place), in the second, it more precisely means "exchange" (one
> object for another).
>
> I'd be interested to know to what extent this ambiguity exists in languages
> other than English - as a somewhat relevant example, ambiguities in English
> around the verb "to be" ("I am Fred", "I am tall", "I am hungry"; i.e.,
> identity vs. attributes vs. state) disappear in other languages which use
> different verbs in each case.
>
> On a (philosophical) side-note, I wonder if this is a real ambiguity: while
> the statement that the name "b" now refers to a different object is
> clear-cut, the other interpretation, that the object itself has changed but
> is somehow still the same object, is a bit of an ontological minefield.
>
> Fortunately, unlike the murky world of philosophy, Python (AIUI) simplifies
> this question by simply declaring that yes, in the case of mutable objects,
> we may say that we are still referring to the same object although we've
> changed it, and no, in the case of immutable objects, we may not, and must
> exchange it if we want a different "value" (a word too fraught with ambiguity
> in this context to use unquoted!).
>
> The sometimes useful fuzziness of human languages means we don't need to ask,
> for example, "how tall is the object currently referred to by the name
> Fred?", but in Python, it helps to understand that this is what's going on.
>
> Regards,
>
> John

There are a few problems going on here.  (My ultimate goal is a
unambiguous, non-arbitrary way to talk about Python; it's just that
unambiguous and non-arbitrary are really tall orders.)  One is the
dependence (supervenience) of meaning on grammar (semantics on syntax,
function on form).  One is the absence of form in computing and math.
Another is the composite identity.

I think the problem goes deeper than just English.  In any language
that has a plural, the propositions in question come out as, 'one
thing is two things' or 'two things are one thing'.  According to some
rules, these are ungrammatical sentences, due to plurality
disagreement.  Ex:

The Morning Star is ...
The Evening Star is ...
*The Morning Star and The Evening Star is...
*The Morning Star and The Evening Star are...

Neither of the latter two is correct.  (* marks ungrammatical.)   As
such, the listener isn't sure what meaning to take.

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.

Identity isn't defined on math objects, only on Python objects; there
is no notion of 'is' in math.  It doesn't make sense to ask if '2 is
2', only if '2=2'.  In Python, they are both defined, and not the
same.  Unfortunately, in the language involved, 'same' and 'different'
aren't opposites, so the communication is horrendous and belabored.

Lastly, equality is a tolerance concept on the computer, not in math.
The computer looks at voltage thresholds in the underlying gates; the
actual voltages, beyond a certain precision, of two representations of
'0110' aren't the same.  Further, the actual voltages of one
representation of '0110' over time aren't equal either.

However, that means, that in order to answer some questions about
equality and identity, we have to address the implementation of the
compiler.  You might get the same answers in many or practically all
implementations of Python, but the specification doesn't make the leap
onto a real computer, where the equivalents of continuity of form are
defined in an unspecified way.  You could even have continuity of the
contents of a byte (word)-- that is, they (the actual voltages on the
individual wires of the word) don't change at all between times t0 and
t1, but an identity test on it fails.  Perhaps composite identity
isn't a common source of problems for language speakers.

P.S.  Didn't say 'value'.