Re: why cannot assign to function call

On Dec 30, 8:21 am, John O'Hagan <m...@xxxxxxxxxxxxxx> 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'.
.