Mark Hammond wrote:
What about Python, where passing an integer to a function passes a
pointer to an int object, but that function is able to change the value
of the variable locally without changing the passed object (indeed, it
is impossible to change the passed integer)?

So given the definitions above, Python uses a by-reference mechanism but
(in some cases) has by-value semantics.

Yeah, Mark, the trouble is that the concepts (by-value, or by-reference) have morphed into a concept(s) that say something of what should or should not happen within scopes (or, in the case of Python, namespaces) and says something less about what 'reference' or 'value' mean as terms for data. So, again, its semantics... not black and white, as you say and some of both|and.

If C were 'strictly' pass-by-value (that is what the K&R states, sec. 1.8, p27 2nd ed) and had no concept of indirect memory addressing (memory references is what we called them in the early days ca. 1970~) in the form of pointers, then all of this semantic discussion would be mute. But, 'C' does provide for pointers which are used by all 'C' programmers to firmly provide pass-by-reference in their coding (C++ also, by the way). My 'C' functions can most definitely modify the parms passed in from their calling functions by simply 'de-referencing' the parms. This is done all the time--- and a good thing too, since nobody would want to pass a list by value, or worse yet a linked list with a couple of thousand nodes, by value.

So, I argue that its silly to say that because the parameter passing 'mechanism' of the 'C' language is pass-by-value (see K&R) that 'C' is a pass-by-value language, when clearly 'C' programmers use pass-by-reference routinely in their 'C' coding. This is quite different than some flavors of Fortran or Pascal where the called routines had access to the original vars--- which had more to do with scope than it did with parameter passing or indirection. In 'C' if I want to I can live with pass-by-value... or, I can live with pass-by-reference nicely... and its up to me... not language constraints. Again, it seems that some folks want to pigeon hole this concept into one or the other (and it clearly can be) but usually it is a combination of the two (both | and).

kind regards,
m harris

--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to