why cannot assign to function call

[Joe Strout]

Aaron Brady wrote:

>> Aaron Brady wrote:
>>> Possible compromise.  You can think of functions as mutation-only.
>>> You pass the object, and it gets a new (additional) name.  The old
>>> name doesn't go in.  </compromise>
>> That's correct.  The reference itself is passed in, not the variable (or
>> expression) that held or generated the reference in the calling code.
> 
> This is very odd, and I see it quite a bit.
> Me: "You pass the object."
> Joe: "That's correct.  You pass the reference."
> 
> What was wrong with my original?

I'm saying that I believe your idea was correct, but worded imprecisely 
(IMHO of course).  So I restated what I believed you were saying, using 
terminology which I believe to be more precise.  If nothing else, this 
gives you the opportunity to say "No, that's not what I meant at all."

>> This is true.  (Technically, instead of variable, we should say "LValue"
>> here -- there are things slightly more complex than simple variables
>> that can serve as the left-hand side of an assignment.  So replace
>> "variable" with "lvalue" above if you prefer.)
> 
> This is a point worth making.  I want to penny-pinch every term in an
> introductory text, though, so, it's a tough call.

Agreed.

>> M2: If 'fun()' returned a reference, you might be able to mutate the
>> object that refers to.
>> m2: You can sometimes mutate the object it refers to.
>> C2: 'fun()' returns a reference.
> 
> This is horrendous.
> http://en.wikipedia.org/wiki/Formal_fallacy
> http://en.wikipedia.org/wiki/Affirming_the_consequent

I did point out that the logic was incorrect (even though the 
conclusion, in this case, happens to be true).

> A question: Are you Joe and you Mark certain that the simplest
> possible introductory explanation makes use of the term 'reference'?

I am.

> Perhaps we can have a contest for shortest/simplest/best description
> of Python's data/variable/argument model.

Sure -- but it judging it might be difficult, requiring some newbies and 
a test to check their comprehension (as you and I pondered once before).

> Lastly, I don't see any reason why we couldn't make both explanations
> available.  'For those coming from Java/etc....; for those coming from
> C++/etc.....'  They would both get read.

Yes, except that the reference explanation applies equally well to 
anyone coming from Java, C/C++, RB, VB.NET, and probably others... I'm 
not sure to whom the other explanation would appeal, unless perhaps it's 
LISP programmers (just a guess, since those on that side of the aisle 
seem to invoke LISP more frequently).


Best,
- Joe