[Edu-sig] Pass by Reference

[David MacQuigg]

Hi John,

I think what we all agree on is the details of what is happening in Python.  As long as we use unambiguous words to describe that process, there is no problem.  The problem is in the definition of "call-by-value".  I have offered a simple definition, what I called the "traditional" definition, but perhaps that is claiming too much priority for one tradition.  I'll call it the "common" definition, what most programmers will tell you, and what you find at http://en.wikipedia.org/wiki/Call_by_value

I know this discussion is getting very old, but I would like to get just one thing resolved.  Can you give us clear and concise definitions of call-by-value and call-by-reference?

At 03:59 PM 5/20/2008 -0500, John Zelle wrote:

>Hi David,
>
>It's enough for me at this point that we all agree on what we're talking
>about. The rest is a matter of "taste," I think. The one real sticking
>point I still have with your approach is simply that what you "expect"
>pass-by-value to do in Python (namely make a copy of the object that a
>variable refers to) is not to my knowledge implemented in any language.

C does call-by-value, at least with primitive objects (according to Kernighan and Ritchie).

>Lots of languages have been built around "pass-by-value," and none is
>doing what you consider your acid-test for pass-by value. On the flip
>side, any language that claims pass-by-reference as part of the language
>allows me to do what I consider the acid test for pass-by-reference
>(namely I can change the referent of the calling argument), which I
>cannot do in Python.

I assume by "change" you mean "re-bind", and by "referent" you mean "object".  It is possible to modify the object of the calling argument.

> So I prefer to use the terms the way they have been
>used historically and remain consistent with language design
>traditions.

I'm finding it hard to understand your terms, perhaps because I'm not familiar with the traditions you refer to.  It would really help if we could use the same words for simple things we all understand.  Here are my suggestions.  
variable:(name, pointer) --> object:(type, value, address) 
re-bind a variable 
modify an object 
copy a pointer 
-- Dave


>On Tue, 2008-05-20 at 10:29 -0700, David MacQuigg wrote:
>> Hi John,
>> 
>> I did some more searching on this question, and I see it has been discussed many times before.  I read a few of the threads, and they seem to go on forever with no resolution, just a lack of communication.  It comes down to the definition of "value".  One camp says a value is only the actual data in an object, the other says the value can be the reference.  I've been using it to mean only the data.
>> 
>>    variable:(name, pointer) --> object:(type, value, address)
>> 
>> Looks like this controversy is not just in the Python community.  I found a good discussion in Bruce Eckel's Thinking in Java, 2nd ed, Appendix A: Passing and Returning Objects.  On p. 1018, he has a discussion of pass-by-value with a nice summary of the views of "two distinct camps".  He concludes with "I will attempt to sidestep the issue.  In the end, it isn't that important.  What is important is that you understand that passing a reference allows the caller's object to be changed unexpectedly."
>> 
>> I think that is what we need to focus on.  What will students remember in later years?  Which explanation will be most beneficial in helping them avoid problems?
>> 
>> I hope that you will recognize the validity of other views, and not just say they are wrong.  I think that is the only way this discussion can move forward.
>> 
>> I wrote a detailed response to your last post, but decided to delete most of it.  I'll just leave a few parts where I need to correct a serious misunderstanding of what I am saying.
>> 
>> At 06:36 PM 5/19/2008 -0500, John Zelle wrote:
>> 
>> >You insist on writing/thinking/reasoning as if Python variables
>> >"contain" the objects they refer to, but that simply is not the case for
>> >the traditional use of the term "variable."
>> 
>> That is not at all what I meant.  In my model the variable has only a name and a pointer.  The variable refers to an object, but it does not "contain" the object, in the sense that a variable in C is like a box containing a value.
>> 
>>    variable:(name, pointer) --> object:(type, value, address)
>> 
>> > Literally, your model,
>> >with the traditional definition would require that every assignment
>> >statement in Python create a new variable. Consider this sequence:
>> >
>> >a = 3 # creates the variable "a"
>> >a = 4 # "a" is now bound to another location
>> >a = 5 # "a" is now bound to yet another location
>> >
>> >Since the address of the value changes with each assignment, the pair
>> >(name, location) is changing each time, and hence we have here three
>> >different variables with the same name. That's certainly not the way I
>> >think about what's happening in Python!
>> 
>> In my model, the pointer associated with the variable named "a" is moved from one object to the next, leaving the old object for the garbage collector.
>> 
>> >So, my question is why don't we just stick with the traditional notion
>> >of a variable being a (name, location) pair.
>> 
>> I've been calling it a (name, pointer) meaning the same thing.
>> 
>> > Realize that Python
>> >dereferences the values for us when we use variables in expressions and
>> >stop trying to invent new names for a parameter passing mechanism that
>> >is identical in function to traditional call by value.
>> 
>> We seem to be coming from different traditions.  In my tradition, call-by-value means copying the actual data to the function, and call-by-reference means copying a reference (pointer).  These definitions include all possibilities, and lead to simple inferences about safety and efficiency, which is the only benefit I can see for discussing the topic with students who are nowhere near being language theory specialists.  The message to my students will be simple - It's like call by reference in C - efficient, but watch out for functions that might modify the objects you send as arguments.
>> 
>> The alternative - like call by value but ... seems a lot more difficult to explain.
>> ... but it is efficient, because the "values" being passed are really just pointers.
>> ... but it is not safe, because the function can modify the caller's arguments.
>> 
>> When I first learned Python, four years ago, I found the discussion in Martelli's book on call-by-value to be confusing, so much so that it impeded my understanding of the simple mechanism that it really is.  This confusion was not resolved until last week when I started researching this question, in response to a student's question in class.  I believe that telling students of C that Python is "call by value" will generate the same confusion that I suffered.  No amount of explanation, or re-assurance "this is what some experts say" will help.
>> 
>> The examples and diagrams in your section 6.5.2 are excellent.  Just for fun, I re-wrote that section keeping everything the same, but changing only the few paragraphs where you talk about call-by-value.  In my humble opinion, that section is shorter and much more clear from a "call-by-reference" point of view.  It avoids having to say that the "values" of variables are actually the pointers, not the data.  It avoids introducing more complex definitions (e.g. "call-by-reference" means that assigning a value to a formal parameter changes the value in the calling program.  That's a result, not a definition, and the result depends on unrelated details of the language, like re-binding semantics.)  It avoids the awkward "Isn't that interesting?" paragraph where you have to explain that in some cases you really can change the caller's object after it has been passed by value.
>> 
>> I'm not saying your definitions are wrong, I just don't see the benefits of adopting these more difficult and more specialized definitions.  Being consistent with some language theorists is not a benefit if it confuses students.
>> 
>> -- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20080521/6e63e6cd/attachment.htm>