why cannot assign to function call

[rurpy at yahoo.com]

Joe Strout wrote:
> rurpy at yahoo.com wrote:
>
>>> I never claimed that you *couldn't* have copy semantics in C; you can do
>>> almost anything you want in C (or C++).  But the *normal* usage of an
>>> array is via a pointer, in which case the semantics are exactly the same
>>> as in Python, Java, REALbasic, .NET, etc.
>>
>> Arrays are the only datatype in C that don't use
>> copy-like assignment.  Everything else does.
>
> No, arrays are just one reference type; pointers are another (and in
> most ways, these are the same thing).

Pointers are passed and assigned by value, just as
other types (disputedly except arrays) are.
One can then use that pointer to manually effect
pass-(the-value-pointed-to)-by-reference, or sharing,
etc.

> When dealing with objects in C++,
> one routinely handles them with pointers, so that's the use case which
> is analogous to Python -- all the value types can be ignored for the
> sake of comparison.  (C is not an OOP language, of course, but even
> there, all but the most trivial of structs are usually allocated on the
> heap and passed around via pointers, just like in C++, Java, .NET, RB,
> and Python.)

In C (you have to explicitly ask for a reference
(pointer) to something (other than arrays) if you
want to use/pass a reference to something.
If you simply use the name, you get by-value semantics.

>>> Ah.  OK then, I guess I missed you're point.  You're absolutely right;
>>> many languages have both reference types and value types.  Python is a
>>> bit unusual in that it has only reference types.  I would have picked a
>>> different example to illustrate that, but it's true nonetheless.
>>
>> If one accepts that there are a "lot" of people
>> who post in here that clearly are surprised by
>> Python's assignment semantics, and further appear
>> to expect assignment to have copy-like semantics,
>> then where is that expectation coming from?
>
> I think it comes from people stumbling across posts in this forum
> claiming that Python has unusual assignment semantics.  I wish people
> would stop saying that, as it causes a lot of confusion.
>
>> How would anyone develop that expectation if (from
>> a different post in this thread), "[Python's] idea
>> of assignment is the same as anyone else's."
>
> I can think of two ways:
>
> 1. They're new to programming in general, and would have had the same
> expectation for any other language.  OR,

IIRC, Someone posted here that his experience was
that 12-year old kids (presumably without programming
experience) had no problem with Python and references
when described as "names given to an object".  (From
memory, can't locate the post right now.)

> 2. They already understand some other language, and then they come here
> and read wild claims that Python's assignment and parameter-passing
> semantics are different from other languages.  Duped by this claim, they
>   conclude that, if it's unlike other languages, then Python must have
> copy semantics.

I have seen no evidence of that.  If it were true I
would expect at least some posts to refer to reading
those "wild claims".

>> If you maintain that reference-like assignment
>> is very common and something every programmer is
>> accustomed to, then where are they getting the
>> copy-like assignment expectations from?
>
> Reference-like assignment IS very common (see
> <http://www.strout.net/info/coding/valref/>).  So, see above.
>
>> I agree that most of the time, when one is using
>> large (memory) composite "objects", and one needs
>> to pass, or access them by different names, one will
>> often use references to do so in order to avoid
>> expensive copies or to get desired "shared" behavior.
>
> Right.
>
>> But (with the exception of C arrays [*1]), doing so
>> requires some special syntax in all the languages I
>> mentioned (AFAIK).
>
> Whether you consider it "special" or not, pointers are extremely common
> in C.  Even more so in C++, which is the closest thing to an OOP
> language in the list of moldy languages you mentioned.

Non-special is "b = a".

> You also mentioned VBA -- if that's anything like VB, it does NOT
> require any special syntax; a variable is a reference type if its
> declared type is a class or string, and a simple type if it's anything
> else (just like in .NET, Java, and REALbasic).

It (mercifully) been a long time since I've used
VB but the VB code I posted does run, and does exhibit
by-value assignment behavior.  My faint recollection
is that if you want to assign a reference you cannot
write, "b = a" but must instead write "set b = a".
"b = a" assigns by value.

In Perl it is definitely true that you different syntax:
@a = (1,2,3)
@b = @a	  # Copy
$b = \@a  # Reference

C is the same way for everything (including pointers)
except arrays:

struct {...} foo;
foo a, b *bp;
b = a;  # Copy
bp = &a; # Reference

>> So it still seems to me that this is a likely
>> explanation to why there is frequent misunderstanding
>> of Python's assignments, and why responding to such
>> misunderstandings with, "Python's assignments are
>> the same as other languages'", is at best not helpful.
>
> I don't think so.  More likely, people are being confused by the claim
> that Python's assignments are NOT like other languages, when in fact
> they are.

It may be one can make a technical case that assignment
is the same, but the reason I posted the code and results,
was because the behavior of "=" in them produces clearly
different results that "=" in Python.  If you want to
then say to someone, "ignore those different results,
'=' works exactly the same", all I can say is good luck.
I will look forward to continuing to see weekly questions
on this list. :-)