> According to who? You're not going to find that phrase in the Scheme > standard, although I realize that the functional programming community often > uses "call by value", and "call by name" or "call by need", to distinguish > between "eager" and "lazy" argument evaluation, respectively. I prefer to > use the plain "eager" and "lazy" for that purpose (although in some contexts > "applicative order" and "normal order" are more natural).
According to Joshua, me and R5RS. R5RS says
"When the procedure is later called with some actual arguments, the environment in which the lambda expression was evaluated will be extended by binding the variables in the formal argument list to fresh locations, the corresponding actual argument values will be stored in those locations, and the expressions in the body of the lambda expression will be evaluated sequentially in the extended environment."
That's call-by-value by definition. (All we need is the middle part about actual argument values being stored in those locations.)
> > => (define (f x) > > (set-car! x -1) > > (set-cdr! x '(-1 -1))) > > F > > => (define y '(1 2 3)) > > Y > > => (f y) > > #unspecified > > => y > > (-1 -1 -1)
> Obviously I don't call that call-by-value.
Then you are wrong. I have no idea why you don't call that call-by-value. Either you don't know what cbv means or you are confused about what r-values are in Scheme. Maybe you should explain what call-by-value means to you so that we can understand where it differs from the correct definition.
> (define y '(1 2 3)) > (define x y) > (set-car! x -1) > (set-cdr! x '(-1 -1)) > y
(-1 -1 -1)
> In a Scheme newsgroup I'd let it pass without comment because of the above
You are wise.
More wise than me. I should have let this pass in this newsgroup, but I was mildly annoyed when Aahz repeatedly told Joshua that he was wrong when Joshua correctly pointed out that Python is call-by-value. Even Guido's Python Tutorial correctly states that Python is cbv.
"Daniel Fackrell" <unlear...@DELETETHIS.learn2think.org> writes: > At the machine level, all that can ever be passed to a > procedure/function/method/whatever is a value, so in a sense, all languages > could be considered to be strictly call-by-value.
This isn't really a problem because that's not what call-by-value means. The term doesn't describe implementation, it describes behavior. You don't determine whether a programming language is cbv by looking at its compilers and interpreters, you look at the behavior of its programs.
In cbv, the parameters are evaluated and their r-values are passed to the function. That's all there is to it.
In article <87el30gcbx....@charter.net>, Doug Quale <qua...@charter.net> wrote:
>In cbv, the parameters are evaluated and their r-values are passed to >the function. That's all there is to it.
Then by that definition, Python is not call-by-value. That's all there is to it. -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/
"In many ways, it's a dull language, borrowing solid old concepts from many other languages & styles: boring syntax, unsurprising semantics, few automatic coercions, etc etc. But that's one of the things I like about it." --Tim Peters on Python, 16 Sep 93
"Fredrik Lundh" <fred...@pythonware.com> writes: > The CLU Reference Manual [2] by Liskov et al says (page 14):
> "We call the argument passing technique _call by sharing_, > because the argument objects are shared between the > caller and the called routine. This technique does not > correspond to most traditional argument passing techniques > (it is similar to argument passing in LISP). In particular it > is not call by value because mutations of arguments per- > formed by the called routine will be visible to the caller. > And it is not call by reference because access is not given > to the variables of the caller, but merely to certain objects."
> Note the use of "does not" and the repeated use of "it is not". > Let me emphasise:
> "IN PARTICULAR IT IS NOT CALL BY VALUE because mutations > of arguments performed by the called routine will be visible to > the caller. And IT IS NOT CALL BY REFERENCE because access > is not given to the variables of the caller, but merely to certain > objects."
I don't know CLU but I suspect that CLU was/is call-by-value. The statement about mutations of arguments and cbv is striking -- it's just plain wrong. This is a remarkably powerful misconception. C array arguments can be mutated and yet C is pure call-by-value.
Barbara Liskov is a smart person and an important programming language researcher (one of the early pioneers of OOP), but saying that CLU is similar to Lisp and yet claiming CLU is not cbv is a contradiction. This is just an error.
The terms "call-by-sharing" and "call-by-object-reference" are fine, but they aren't particularly popular in the programming language research community. I suspect this is because they don't really say anything -- they both describe call-by-value.
If you say that Python is call-by-object-reference, then you would also have to say that Python is assignment (or binding) by object reference, because the value of x inside f() in
def f(x): x[:] = [-1] * 3
y = [1, 2, 3] f(y)
is exactly the same as if x were bound directly, as in
y = [1, 2, 3] x = y x[:] = [-1] * 3
That's OK, but it's much simpler and saner to just say that Python binding and function calls work the same way. In both cases the r-values are object references. When looking at the Python statement
x = y
I say that x is bound to the value of y (and the value of y is a reference to some object), not x is bound to a reference to the value of y. If you choose to say "reference to the value of y" then values will never appear in any description of Python -- everything will be references to values. This is silly. The values are object references, and everything follows smoothly.
Using a name different from cbv is necessary when function parameters are bound differently than they are by an assignment statement. This happens in Fortran (call-by-reference), Algol (call-by-name), etc. It doesn't appear to happen with call-by-sharing or call-by-value.
> Why are arrays different? You and I both just said that C was call by > value. Well, C is call by value. The r-value of a C struct is the > struct, but the r-value of a C array is a reference to the first > element in the array.
More basic than that. An array as an argument to a function call is treated precisely as if it were written as a pointer. So when you declare a function taking an array, you're really declaring a function taking a pointer. (You can even test this with sizeof; it will return the size of the _pointer_, not the declared array.)
So you're not passing a reference to the first element, you're passing a pointer by value. (And if what you were passing on the calling side was an array, you're just taking advantage of the fact that an array name decays to a pointer to the first element.)
> Some people might explain it by saying that in C, scalars and > structures are passed by value and arrays are passed by reference.
Structures are passed by value; if you have a struct as an argument, a copy is made.
-- Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/ __ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE / \ Life is not a spectacle or a feast; it is a predicament. \__/ George Santayana
> > There's no rational sense in which that can be called call-by-value.
> It's call-by-value-where-all-values-are-references, which is awfully > confusing to simply abbreviate as "call-by-value."
It is call-by-value-where-all-values-are-references. (Describing argument passing semantics doesn't describe the nature of values in the language, so simply call-by-value suffices.) I don't agree that it's awfully confusing, although clearly I am wrong considering how much confusion we've seen in this thread.
How do you explain assignment (binding) in Python? The values there are references too, right?
Doug Quale wrote: > No, that's exactly what call-by-value means when applied to Python values > (actually r-values). What happens when you try this:
> >>> y = [1, 2, 3] > >>> x = y > >>> x[:] = [-1]*3 > >>> y > [-1, -1, -1]
> Same behavior, no function calls.
except that "x[:] =" *is* a method call.
x[:] = [-1]*3 passes a slice object and the result of ([-1]*3) to the x.__setitem__ method, using the standard calling mechanism (that's what the "the object is asked" stuff in the language ref means)
"x.y =" is also a method call (__setattr__).
so is "x[y] =" (__setitem__, again).
however, "x = y" isn't.
(and thirty years ago, CLU also had syntactic sugar that looked like assignments for the uninformed observer, but really was yet another way to call a procedure. nothing new here.)
> I don't know CLU but I suspect that CLU was/is call-by-value. The > statement about mutations of arguments and cbv is striking -- it's > just plain wrong. This is a remarkably powerful misconception. > C array arguments can be mutated and yet C is pure call-by-value.
I think that you are being overly dogmatic. All argument passing can be labeled as call-by-value because, at some level, it must be i.e. my compiler generates the same code for:
void f(int *) and void f(int &)
The real question is, without thinking about implementation, what call type best describes Python method calls? One of my CS textbooks has the following definition:
"""(CBV) An evaluation strategy where arguments are evaluated before the function or procedure is entered. Only the values of the arguments are passed and changes to the arguments within the called procedure have no effect on the actual arguments as seen by the caller."""
That certainly does not explain the behavior of Python calls.
Doug Quale wrote: > According to Joshua, me and R5RS. R5RS says
> "When the procedure is later called with some actual > arguments, the environment in which the lambda expression was evaluated will > be extended by binding the variables in the formal argument list to > fresh locations, the corresponding actual argument values will be stored > in those locations, and the expressions in the body of the lambda expression > will be evaluated sequentially in the extended environment."
> That's call-by-value by definition.
but that's not how Python works.
in Python, the variables in the formal argument list are bound to the actual argument objects. the objects are _shared_ between caller and callee; there are no "fresh locations" or extra "stores" involved.
(which, of course, is why the CLU folks called this mechanism "call- by-sharing". and they were real computer scientists, working for a real computer science laboratory ;-)
and btw, Python functions doesn't run in an extended environment, either. function bodies have very limited access to the surrounding environment. but that's another story.
> It's only here that I disagree with you. I consider Python values > themselves to be object references, which are simply copied/assigned > to the formal parameters upon function invocation.
To me and, I believe, most pythoneers, the value of an int object is its integer value: ..., -1, 0, 1, ... . The value of a string object is its sequence of bytes. A 'reference' to a Python object is *not* a Python object. It is whatever a non-godly interpreter, human or machine, needs to associate (non-object) names and container object slots with Python objects.
> Where I do agree with you is that it's an implementation detail that > these object references are implemented as C pointers.
Only in the C-coded interpreter. The Java-coded interpreter does something else. No one seems to know quite how we humans associate name with objects or if 'reference' will be part of some future description.
> Ok, enjoyable conversation, but I think we're starting to retread old > ground.
So let me inject a somewhat different thought. C, for example, is pretty explicitly a language for computer execution: variables are sized blocks of memory with integer addresses subject to addition and subtraction. (I am aware of the Intel exception, and of non-standard kludges like 'near' and 'far'.) Python is a more general algorithm language defined in terms of names, typed information units (objects), undefined, interpreter-implemented, 'associations' between the two, and operations on the information values. It is optimized more for human interpretation than execution speed, but, unlike algorithm pseudocodes, is also machine interpretable. That's why I dubbed it 'executable pseudocode' over 6 years ago. (The semi-oxymoronic irony was intentional). While some may not like this viewpoint, others like me find it useful, which is what viewpoints are about.
> You're right. I meant the values are references to objects.
"reference to object" is an implementation concept and method, but not a 'value' in the abstract universe defined by Python, the information algorithm language. Python the language is not (C)Python, the standard C-coded machine implementation. Your statement is true, or can be reasonably seen to be so, in reference to the C implementation, but it is not necessarily even very meaningful from a more abstract viewpoint. So if we are talking in different contexts, it is not surprising we evaluate the statement differently.
> > Essentials of Programming Languages > > Daniel P. Friedman, Mitchell Wand, Christopher Thomas Haynes
> if all you have is scheme, etc.
It's a good reference to programming languages in general. The authors are prominent researchers in the field. Scheme provides a good basis for discussing many programming language concepts, although its syntax doesn't demonstrate very much about issues involved in parsing. From the description you give below CLU doesn't offer much more.
> in case your PDF reader is broken, here are the relevant portions from > that document (any typos etc added by me).
> "The basic elements of CLU semantics are _objects_ and > _variables_. Objects are the data entities that are created and > manipulated by CLU programs. Variables are just the names used > in a program to refer to objects.
Same as Scheme and Lisp.
> In CLU, each object has a particular _type_, which characterizes > its behavior. A type defines a set of operations that create > and manipulate objects of that type. An object may be created > and manipulated only via the operations of its type.
Same as Scheme and Lisp. Types are associated with objects (values), not variables. This is strong dynamic (or latent) typing. (CLU might be statically typed since you can't tell from these excerpts, but I suspect that it is dynamically typed.)
> An object may _refer_ to objects. For example, a record object > refers to the objects that are the components of the record. > This notion is one of logical, not physical, containment. In > particular, it is possible for two distinct record objects to > refer to (or _share_) the same component object. In the case of > a cyclic structure, it is even possible for an object to > "contain" itself. Thus it is possible to have recursive data > structure definitions and shared data objects without explicit > reference types. /.../
Same as Scheme and Lisp.
> CLU objects exist independently of procedure activations. Space > for objects is allocated from a dynamic storage area /.../ In > theory, all objects continue to exist forever. In practice, the > space used by an object may be reclaimed when the object isno > longer accessible to any CLU program.
Indefinite extent + garbage collection, same as Scheme and Lisp.
> An object may exhibit time-varying behavior. Such an object, > called a _mutable_ object, has a state which may be modified by > certain operations without changing the identity of the > object. /.../ > If a mutable object _m_ is shared by two other objects _x_ and > _y_, then a modification to _m_ made via _x_ wil be visible when > _m_ is examined via _y_. /.../
Same as Scheme and Lisp. Note that in pure functional languages all values are immutable. Scheme and Lisp are not pure.
> Objects that do not exhibit time-varying behavior are called > _immutable_ objects, or constants. Examples of constants are > integers, booleans, characters, and strings. The value of a > constant object can not be modified. For example, new strings > may be computed from old ones, but existing strings do not > change. Similarily, none of the integer operations modify the > integers passed to them as arguments.
Same as Scheme and Lisp except that strings are mutable in those languages.
> Variables are names used in CLU programs to _denote_ particular > objects at execution time. Unlike variables in many common > programming languages, which _are_ objects that _contain_ > values, CLU variables are simply names that the programmer uses > to refer to objects. As such, it is possible for two variables > to denote (or _share_) the same object. CLU variables are much > like those in LISP and are similar to pointer variables in other > languages. However, CLU variables are _not_ objects; they > cannot be denoted by other variables or referred to by > objects. /.../
Same as Scheme and Lisp. Same as C treatment of arrays and pointer values.
> The basic actions in CLU are _assignment_ and _procedure > invocation_. The assignment primitive 'x := E' where _x_ is a > variable and _E_ is an expression, causes _x_ to denote the > object resulting from the evaulation of _E_. For example, if > _E_ is a simple variable _y_, then the assignment 'x := y' > causes _x_ to denote the object denoted by _y_. The object is > _not_ copied, it will be _shared_ by _x_ and _y_. Assignment > does not affect the state of any object. (Recall that 'r.s := > v' is not a true assignment, but an abbreviation for 'put.s(r, > v)'.)
Same as Scheme and Lisp, although naturally the syntax is different. Scheme uses (define x E) and (set! x E) for assignment. Lisp uses (setq x E).
> Procedure invocation involves passing argument objects from the > caller to the called procedure and returning result objects from > the procedure to the caller. The formal arguments of a > procedure are considered to be local variables of the procedure > and are initialized, by assignment, to the objects resulting > from the evaluation of the argument expressions. Thus argument > objects are shared between the caller and the called procedure. > A procedure may modify mutable argument objects (e.g. records), > but of course it cannot modify immutable ones (e.g. integers). > A procedure has no access to the variables of its caller.
This is a description of call-by-value using CLU values (object references). Note that CLU values used in variable assignment and the binding done by argument passing are the same. This is the key point.
> Procedure invocations may be used directly as statements; those > that return objects may also be used as expressions. Arbitrary > recursive procedures are permitted."
> replace "CLU" with "Python", "record" with "instance", and "procedure" > with "function or method", and you get a pretty accurate description > of Python's object model.
> if you don't agree, please tell us what Python does differently. be very > specific.
It describes Python very well. Since it also describes a call-by-value argument passing semantics, one can conclude that CLU and Python, like Scheme and Lisp, are call-by-value.
If you don't agree that this describes call-by-value argument passing, tell us what Python does differently. Be very specific.
Brian Quinlan wrote: > I think that you are being overly dogmatic. All argument passing can > be > labeled as call-by-value because, at some level, it must be i.e. my > compiler generates the same code for:
> void f(int *) and > void f(int &)
But saying this all boils down to call-by-value misses the point. Distinctions between call-by-value and call-by-reference aren't about the _implementation_, they're about the high-level behavior of the language.
Python as a language is closer to call-by-reference than call-by-value, but it's really best described as something in between or different, since "references" in Python are bindings and don't have the same kind of long-lasting meaning that they do in, say, C++.
-- Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/ __ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE / \ My life was better before I knew you. \__/ Edith Wharton (to Morton Fullerton)
> The actual parameters (arguments) to a function call are introduced in > the local symbol table of the called function when it is called; thus, > arguments are passed using _call by value_ (where the _value_ is always > an object reference, not the value of the object).
it's a trick ;-)
if you read that sentence carefully, with the original emphasis left intact, you'll notice that he says that python uses "_call by value_ where _value_ is not the value of the [argument]".
which clearly isn't the _call-by-value_ that FOLDOC talks about when they say that "Only the values of the arguments are passed"...
_Objects_ are Python's abstraction for data. All data in a Python program is represented by objects or by relations between objects.
Every object has an identity, a type and a value. An object's _identity_ never changes once it has been created; you may think of it as the object's address in memory. /.../ An object's _type_ is also unchangeable. It determines the operations that an object supports (e.g., ``does it have a length?'') and also defines the possible values for objects of that type. /.../ The _value_ of some objects can change. Objects whose value can change are said to be _mutable_; objects whose value is un- changeable once they are created are called _immutable_.
(this is basically the same terminology as in the CLU papers, except that they used the term "state" instead of Python's "value")
...so I guess what you've been saying all the time is that Python uses call-by-identity, not call-by-state. fair enough.
Fredrik Lundh <fred...@pythonware.com> wrote: > Joshua Marshall wrote: >> It's only here that I disagree with you. I consider Python values >> themselves to be object references > if you keep inventing your own terminology, you'll never win this > argument:
I've quoted it elsewhere in the thread, but I'll do it again here. From
The actual parameters (arguments) to a function call are introduced in the local symbol table of the called function when it is called; thus, arguments are passed using call by value (where the value is always an object reference, not the value of the object).
Is "object reference" the term you claim I made up?
> http://www.python.org/doc/current/ref/objects.html > "Objects, values and types" > _Objects_ are Python's abstraction for data. All data in a > Python program is represented by objects or by relations > between objects.
The documentation is a little schizophrenic about "objects" versus "object references", but this isn't a problem, since Python has no dereferencing operator.
Quoth Doug Quale <qua...@charter.net>: | "Fredrik Lundh" <fred...@pythonware.com> writes: ... [ quoting account of CLU system (by Barbara Liskov?) ] ... |> Objects that do not exhibit time-varying behavior are called |> _immutable_ objects, or constants. Examples of constants are |> integers, booleans, characters, and strings. The value of a |> constant object can not be modified. For example, new strings |> may be computed from old ones, but existing strings do not |> change. Similarily, none of the integer operations modify the |> integers passed to them as arguments. | | Same as Scheme and Lisp except that strings are mutable in those languages.
What does ``the value of a constant object cannot be modified'' mean? Is it possible that by "value", the author means the computer data represented by the object?
| This is a description of call-by-value using CLU values (object | references). Note that CLU values used in variable assignment and the | binding done by argument passing are the same. This is the key point.
Does this key point require that we always expect "value" in the context of CLU to mean "object reference"? Or would you agree that this would actually be absurd, except in the context of "call-by-value" where we know it must have that meaning because Python passes object references, Python is like Scheme and Scheme is call-by-value?
Erik Max Francis wrote: > But saying this all boils down to call-by-value misses the point. > Distinctions between call-by-value and call-by-reference aren't about > the _implementation_, they're about the high-level behavior of the > language.
> ... > I should have let this pass in this newsgroup, but I was mildly annoyed > when Aahz repeatedly told Joshua that he was wrong when Joshua correctly > pointed out that Python is call-by-value. Even Guido's Python Tutorial > correctly states that Python is cbv.
And corrected it with a footnote because, as you haven't yet picked up, calling Python cbv isn't *helpful*. I'll repeat a msg from 2 years ago:
I usually say Python does "call by object". Then people go "hmm, what's that?". If you say "call by XXX" instead, then the inevitable outcome is a tedious demonstration that it's not what *they* mean by XXX. Instead I get to hear impassioned arguments that "by object" is what any normal person means by YYY <wink>.
I'll note now that you (and Joshua, and so far) fit into the last sentence of that, with YYY == "call by value". You're not the first <wink>.
BTW, I believe Barbara Liskov first coined "call by object" to describe argument-passing in CLU.
A primary difference between you and Joshua and responders (including me, Aahz, Jeremy, Fredrik and Terry), is that we've been explaining Python to newcomers for many years. The idea that "call by value" has One True Objective Meaning is simply silly, as actually doing the literature search I suggested at the start would have shown you. It's used to mean several distinct things, depending on the programming culture using it. Even so, in no case does it have enough explanatory power to answer most practical questions about the semantics of calls in Python. Therefore it's useless as a pedagogical device here. In contrast, Liskov's description of "call by object reference" explains just about everything, and applies almost verbatim to CLU, Smalltalk, Python, and-- with a little bit of squinting to exempt special forms and macro calls --a majority of Lisp variants.
So I don't care what you (or Joshua) want to insist "call by value" means -- no matter what it means to you, it doesn't *help* here. If you care to learn something new, I recommend Henry Baker's "Equal Rights for Functional Objects", which argues the issue in detail in the context of Lisp:
I'll just quote the start of section 7 ("Call-by-reference versus call-by-value") here:
Despite the thirty years that the problem of "call-by-reference" versus "call-by-value" in argument-passing semantics of Algol-like programming languages has been discussed, it has never been clearly resolved. While many undergraduate texts [Aho86,s.7.5] and language manuals give a definition of each policy, there has always been a nagging feeling that these definitions for Algol-60, Fortran and Ada are too ad hoc and too implementation-oriented.
...
We claim that the only argument-passing model that is consistent in non-functional languages is call-by-object-reference, i.e., passing object identities.
He goes on to explain why it's incorrect to call Lisp "call-by-value", and I agree -- provided that by "call-by-value", you mean the One True Objective Meaning it had when I was your age <wink -- I'm afraid it had several meanings then too, and that's only gotten worse, the most recent abuse being the widespread adoption (in one sub-culture) of using cbv to mean applicative-order evaluation>.
If thinking of Python as being cbv helps you to understand it, I certainly don't object to that. The evidence of the last decade is that it actively hinders understanding for most newcomers, but that explaining call-by-object actively helps.
stick-around-and-you'll-eventually-agree-ly y'rs - tim
) for why a venerable Lisp expert believes "call by value" is incorrect even for describing Lisp -- but he doesn't mean the same thing by "call by value" that you mean. That alone doesn't mean he's wrong either <wink>.
Brian Quinlan <br...@sweetapp.com> writes: > The real question is, without thinking about implementation, what call > type best describes Python method calls? One of my CS textbooks has the > following definition:
> """(CBV) An evaluation strategy where arguments are evaluated > before the function or procedure is entered. Only the values > of the arguments are passed and changes to the arguments > within the called procedure have no effect on the actual > arguments as seen by the caller."""
> That certainly does not explain the behavior of Python calls.
Your CS textbook is wrong -- what is the name of the book?
Very precise definition of call-by-value would require denotational semantics (Stoy, Reynolds, etc.) which is out of my league. Fortunately this idea really isn't that hard so we can take a more informal view.
"Compilers: Principles, Techniques and Tools" by Aho, Sethi and Ullman
"Call-by-Value
This is, in a sense, the simplest possible method of passing parameters. The actual parameters are evaluated and their r-values are passed to the called procedure. Call-by-value is used in C, and Pascal parameters are usually passed this way."
Call-by-value isn't about implementation, it's about behavior. It explains the behavior of Python calls. If you think that it doesn't, then demonstrate a Python function call that doesn't get passed the r-values of its parameters.
In Tim Peter's example,
>>> def f(x): >>> x[:] = [-1] * 3
>>> y = [1, 2, 3] >>> id(y) 135448932 >>> f(y) >>> y [-1, -1, -1] >>> id(y)
135448932
the variable (name) y is bound to a list object. List objects are mutable in Python. During the call f(y), the local name x is bound to the same object as y. After the call f(y), the name y is still bound to the *same* object. The call f(y) mutated that object, but y's binding has *not* changed. This in itself doesn't make Python call-by-value, but it doesn't rule out c-b-v either. C arrays behave in exactly the same way and C is c-b-v. In order to apply the definition of c-b-v to Python we need to know what Python r-values are. The r-value is used when you assign directly:
>>> y = [1, 2, 3] >>> id(y) 135448932 >>> x = y >>> id(x) 135448932 >>> x[:] = [-1] * 3 >>> y [-1, -1, -1] >>> id(x) 135448932 >>> id(y)
135448932
Same behavior. You can see that Python functions are passed r-values (the values used for the right sides of assignments). Other calling mechanisms such as call-by-reference, call-by-name and call-by-copy-in-out do not behave this way.
The Pythonistas' meme about what call-by-value is would indicate that C and Java are not call-by-value. (In fact only pure functional languages would qualify, and there's already good terminology to describe them -- "pure functional language".) This is incorrect, as can be seen by applying the correct definition of c-b-v. It seems that people are making this too complex by thinking that c-b-v means more than it really does.
"Terry Reedy" <tjre...@udel.edu> writes: > "Doug Quale" <qua...@charter.net> wrote in message > news:87n0hogdjd.fsf@charter.net... > > You're right. I meant the values are references to objects.
> "reference to object" is an implementation concept and method, but not > a 'value' in the abstract universe defined by Python, the information > algorithm language. Python the language is not (C)Python, the > standard C-coded machine implementation. Your statement is true, or > can be reasonably seen to be so, in reference to the C implementation, > but it is not necessarily even very meaningful from a more abstract > viewpoint. So if we are talking in different contexts, it is not > surprising we evaluate the statement differently.
No. Reference is not an implementation concept, it's a semantic concept and completely abstract. Saying y is a reference to a list object in
y = [1, 2, 3]
is the same thing as saying that y denotes a list object.
If you think this is not so, explain what a Python value is.
