So we can say that Python is call-by-reference, but surely not whe the
data is imutable---then Python is sometimes call-by-reference.
My understanding that in a call-by-reference language, the variables themselves are passed ...
Scheme is call-by-value. Python is call-by-value. Java is
call-by-value. C is call-by-value. In none of those languages can you
write a procedure that assigns a variable used as an argument to that procedure. Read that carefully. "Assigns" means to change what the
variable references. "Assigns" does _not_ mean to make modifications to
the thing that the variable references. In Python terms "x = 4" is an assignment to "x", but "x[1] = 4" is not an assignment to "x" because afterwards "x" still references the same object.
English is a bit slippery here, so people often find this distinction confusing. To make it clearer ask yourself what it means to "change
your socks". Does it mean you took your socks off and put on a
different pair? Or does it mean you dyed the socks you are wearing a different color?
A call by value language doesn't let you put on a different pair of
socks, it only lets you dye them a different color.
Johanne Fairchild <jfairchild@tudado.org> writes:
If I understand it right, call-by-reference means the same variable that
was outside of a procedure call gets passed in to the procedure. So if
I assign a new value to it, it /must/ change the value outside because
it is the /same/ variable. So I would've expected the analogy to
somehow say that call-by-reference doesn't let me change socks at all.
You would? You must be completely mis-interpreting my analogy because I cannot for the life of me figure out how you came to that expectation!
But don't sweat it -- it's just an analogy. Stick to what I said
first: "x[1] = 4" does not make "x" refer to a different thing.
Languages such as C and C++ are interesting in this regard, as they have
only call-by-value semantics, but also support passing explicit
pointers, which allows them to simulate call-by-reference semantics by
the passing of explicit pointers.
I apologize, I lost my train of thought for part of this:
Schol-R-LEA:
In call-by-reference, what is passed is a pointer or similar reference
to the
...to the variable.
In effect, a language in which call-by-reference is used, parameters are implicit pointers to the arguments. So, by comparison to C,
void foo(int bar)
{
bar = 23;
}
in a call-by-reference dialect would be equivalent to
void foo(int* bar)
{
*bar = 23;
}
in standard C.
For obvious reasons, this presents problems with potential side effects
and is harmful to modularity, as any change to the parameter variable
would silently change the argument. This is why most languages which
support call-by-reference at all do so explicitly, with call-by-value
being the default.
... but for mutable entities it behaves like call by reference ...
On Thu, 21 Mar 2024 18:08:12 +0000, Chris Vine wrote:
... but for mutable entities it behaves like call by reference ...
This has already been discussed. Only parts of the passed entity can be mutated this way, it cannot be replaced with another complete entity as
far as the caller is concerned. Thus, it is still “call by value”.
On Thu, 21 Mar 2024 21:12:36 -0000 (UTC) Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:
On Thu, 21 Mar 2024 18:08:12 +0000, Chris Vine wrote:
... but for mutable entities it behaves like call by reference ...
This has already been discussed. Only parts of the passed entity can be
mutated this way, it cannot be replaced with another complete entity as
far as the caller is concerned. Thus, it is still “call by value”.
Which part of:
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 399 |
Nodes: | 16 (2 / 14) |
Uptime: | 39:49:46 |
Calls: | 8,336 |
Calls today: | 13 |
Files: | 13,155 |
Messages: | 5,891,348 |
Posted today: | 1 |