Finding the instance reference of an object

[Terry Reedy]

Re: Finding the instance reference of an object

greg wrote:

>
No. Passing q by value means that the value of the expression 'q',
whatever that is in the language concerned, gets assigned to the
local variable 'p', whatever *that* means in the language concerned.

In other words, as I acknowledged in my other post, one can say that all
calling is calling by value.

[greg]

Re: Finding the instance reference of an object

Arnaud Delobelle wrote:

// What is passed to foo below is obviously not a 'variable
// reference' as the argument is not a variable.
foo(a[3]); // Now a[3] == 7
foo(b.i); // Now b.i == 7

Yes, it is. By "variable" I mean what C calls an lvalue,
i.e. something you can assign to.

I'm not sure that your definition of 'call by value' is widely
accepted. If it was, then this thread wouldn't exist.

It seems to be accepted by the Java and VB community,
judging by what they refer to as call-by-value in those
languages.

You won't necessarily find it written down anywhere in
the exact words I used. I have reverse-engineered it
from the characteristics of a wide variety of languages
that use the term call-by-value to describe one of their
parameter passing mechanisms. Think of it as a theory
that fits the observed linguistic facts.

(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 hinges on what exactly is meant by "changes to
the arguments". In Python it can only mean assigning
directly to the bare name -- anything else isn't
changing the argument itself, but something else to
which the argument refers.

--
Greg

[greg]

Re: Finding the instance reference of an object

Terry Reedy wrote:

In other words, as I acknowledged in my other post, one can say that all
calling is calling by value.

No, those are not other words for what I'm saying.
Call by reference is very demonstrably different
from call by value, as has been pointed out a large
number of times already.

--
Greg

[Terry Reedy]

Re: Finding the instance reference of an object

greg wrote:

Arnaud Delobelle wrote:
>

> (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 hinges on what exactly is meant by "changes to
the arguments".

Mutating them, like Python does, which is why calling Python CBV leads
people to write buggy code.

>In Python it can only mean assigning
directly to the bare name -- anything else isn't
changing the argument itself, but something else to
which the argument refers.

Hogwash. The argument is the object and mutable objects can be changed
as seen by the caller.

[Joe Strout]

Re: Finding the instance reference of an object

On Nov 10, 2008, at 8:30 AM, Terry Reedy wrote:

>That hinges on what exactly is meant by "changes to
>the arguments".

>
Mutating them, like Python does, which is why calling Python CBV
leads people to write buggy code.
>

In Python it can only mean assigning
>directly to the bare name -- anything else isn't
>changing the argument itself, but something else to
>which the argument refers.

>
Hogwash. The argument is the object and mutable objects can be
changed as seen by the caller.

By that definition, Java, REALbasic, C++, and VB.NET are all call-by-
reference too (even when explicitly using the "ByVal" keyword in RB/
VB.NET). This will come as quite a shock to the designers and users
of those languages.

For what it's worth, I think Greg (double-quoted above) has it exactly
right. The argument in any of these languages is an object reference;
changing the object and changing the object reference are two
different things.

Best,
- Joe

[Terry Reedy]

Re: Finding the instance reference of an object

Joe Strout wrote:

On Nov 10, 2008, at 8:30 AM, Terry Reedy wrote:
>

>>That hinges on what exactly is meant by "changes to
>>the arguments".

>>
>Mutating them, like Python does, which is why calling Python CBV leads
>people to write buggy code.
>>

>In Python it can only mean assigning
>>directly to the bare name -- anything else isn't
>>changing the argument itself, but something else to
>>which the argument refers.

>>
>Hogwash. The argument is the object and mutable objects can be
>changed as seen by the caller.

>
By that definition, Java, REALbasic, C++, and VB.NET are all
call-by-reference too (even when explicitly using the "ByVal" keyword in
RB/VB.NET). This will come as quite a shock to the designers and users
of those languages.
>
For what it's worth, I think Greg (double-quoted above) has it exactly
right. The argument in any of these languages is an object reference;
changing the object and changing the object reference are two different
things.

[Terry Reedy]

Re: Finding the instance reference of an object

Joe Strout wrote:

On Nov 10, 2008, at 8:30 AM, Terry Reedy wrote:
>

>>That hinges on what exactly is meant by "changes to
>>the arguments".

>>
>Mutating them, like Python does, which is why calling Python CBV leads
>people to write buggy code.
>>

>In Python it can only mean assigning
>>directly to the bare name -- anything else isn't
>>changing the argument itself, but something else to
>>which the argument refers.

>>
>Hogwash. The argument is the object and mutable objects can be
>changed as seen by the caller.

>
By that definition, Java, REALbasic, C++, and VB.NET are all
call-by-reference too (even when explicitly using the "ByVal" keyword in
RB/VB.NET). This will come as quite a shock to the designers and users
of those languages.
>
For what it's worth, I think Greg (double-quoted above) has it exactly
right. The argument in any of these languages is an object reference;

In the Python I am talking about, the language defined in the Python
Reference Manual, arguments are objects.

Bye,

tjr

[Aaron Brady]

Re: Finding the instance reference of an object [long and probablyboring]

On Nov 7, 3:03 pm, Arnaud Delobelle <arno...@google mail.comwrote:

1. Is Napoleon a copy of Dobby or are they the same cat?
>
2. Is Polion a copy of Napoleon or are they the same cat?
>
3. When we got rid of Napoleon's fleas, was Nelson deflea-ed as well?
>
4. When Napoleon died, did Nelson die as well?
>
5. When we got a new Napoleon, does this mean that our neighbours got a
   new Nelson?
>
Now a question about the questions about the story:
>
   To be able to understand the story and answer questions 1-5, do we
   need to think of Napoleon, Nelson and Polion as variables containing
   references to cat objects, or is it enough to think of them as three
   names for cats?

Do you ever say to someone, "'Napoleon' will no longer refer to
Nelson. It is this lobster now instead", while you are holding a
lobster?

My point is that the assignment operation is rare in natural language.

Some examples:

unitedstates.pr esident= people['Barack Obama']
catholicchurch. pope= people['Joseph Ratzinger']
chicagocubs.man ager= people['Lou Pienella']

That is, in January, 'The President' will start to refer to a
different person. But you don't see:

popstars['Britney Spears']= people['Ricky Martin']
people['Richard Nixon']= people['Ronald Reagan']

You also have expressions, such as 'the man in the corner drinking
Coke' and 'the first street on the right', which would not be likely
to be modeled as attributes, per se, such as:

corner.men.drin king['Coke']
street.ontherig ht[0]

You'd more likely use:

"select id from people where standingin = 'corner' and drinking =
'coke'"
"select id from streets where distanceonright =
min( distanceonright )"

Maybe in the future we'll see relational code, rather than
hierarchical subclasses:

>>"select fly from birds where name = 'bluejay'"

'flap_wings()'

>>"select fly from birds where name = 'ostrich'"

'raise CannotFlyExcept ion'

[Arnaud Delobelle]

Re: Finding the instance reference of an object [long and probably boring]

Aaron Brady <castironpi@gma il.comwrites:

Do you ever say to someone, "'Napoleon' will no longer refer to
Nelson. It is this lobster now instead", while you are holding a
lobster?

Not explicitly. But in the course of conversation I might refer to
Napoleon, meaning Napoleon Bonaparte (1769 - 1821) or Napoleon III (1808
- 1873). There would then be an implicit 'rebinding' of the name Napoleon.

My point is that the assignment operation is rare in natural language.

My point was to get away from a model for Python which was built on its
likely implementation and to hint that we can build one using the naive
concept of 'name for a thing' instead. IOW, 'call by value' is an
unnecessary obfuscation of what *actually* happens (even though it may
describe accurately the artifacts employed by an implementation)

I'm glad that you thought about it!

--
Arnaud

[Aaron Brady]

Re: Finding the instance reference of an object [long and probablyboring]

On Nov 10, 2:45 pm, Arnaud Delobelle <arno...@google mail.comwrote:

Aaron Brady <castiro...@gma il.comwrites:

Do you ever say to someone, "'Napoleon' will no longer refer to
Nelson.  It is this lobster now instead", while you are holding a
lobster?

>
Not explicitly.  But in the course of conversation I might refer to
Napoleon, meaning Napoleon Bonaparte (1769 - 1821) or Napoleon III (1808
- 1873).  There would then be an implicit 'rebinding' of the name Napoleon.
>

My point is that the assignment operation is rare in natural language.

>
My point was to get away from a model for Python which was built on its
likely implementation and to hint that we can build one using the naive
concept of 'name for a thing' instead.  IOW, 'call by value' is an
unnecessary obfuscation of what *actually* happens (even though it may
describe accurately the artifacts employed by an implementation)
>
I'm glad that you thought about it!

I agree with Terry that all calling is call-by-value, and Steven that
all calling is call-by-bit-flipping. I agree with Joe that call-by-
object is a special case of call-by-value.

I thought of another way Python's passing method could be
implemented. Parameters are passed as namespace-name pairs, and every
time a variable occurs, it's looked up in the namespace it's in. If
it's changed (concurrently) in the outer scope, a copy is made into
the inner scope. If it's changed in the inner scope, a new entry is
added there.

It's still call-by-value (and bit-flipping) on some level, in the
trivial sense. What else is it?

[Joe Strout]

Re: Finding the instance reference of an object [long and probablyboring]

On Nov 10, 2008, at 2:30 PM, Aaron Brady wrote:

I agree with Terry that all calling is call-by-value, and Steven that
all calling is call-by-bit-flipping. I agree with Joe that call-by-
object is a special case of call-by-value.

Woo! Almost sounds like approaching consensus. :)

However, I'm sorry to say that I think both Terry's and Steven's
descriptions are unhelpful. There really are important distinctions
among parameter evaluation strategies. Call-by-reference is not call-
by-value (though it is call-by-bit-flipping, but that's too low a
level).

But if we can agree that call-by-sharing (which I believe is the more
widely documented term than "call-by-object") is a special case of
call-by-value, when the parameters are object references, then I think
we may have a winner.

Best,
- Joe

[Steven D'Aprano]

Re: Finding the instance reference of an object

On Mon, 10 Nov 2008 08:39:58 -0700, Joe Strout wrote:

By that definition, Java, REALbasic, C++, and VB.NET are all call-by-
reference too (even when explicitly using the "ByVal" keyword in RB/
VB.NET).

No, they are not call-by-reference either. They are call-by-sharing, just
like Python and CLU.



--
Steven

[Steven D'Aprano]

Re: Finding the instance reference of an object

On Mon, 10 Nov 2008 23:16:13 +1300, greg wrote:

> (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 hinges on what exactly is meant by "changes to the arguments". In
Python it can only mean assigning directly to the bare name -- anything
else isn't changing the argument itself, but something else to which the
argument refers.

But the name isn't the argument. The argument to a function is an object,
not a name. You can't write a function in Python that takes a name as an
argument[1], which would be equivalent to Pascal's "var" parameters.

Take a function foo that takes one formal parameter x. Pass an actual
argument y to it. The argument is the object currently bound to y, not
the name y. Nothing inside foo can rebind the name y because foo doesn't
see the name y, it sees the object. Rebinding (or deleting) the name x
inside foo does nothing to the object bound to y, or the name y.






[1] You can pass a string representing the name to a function, which can
then use some combination of setattr, globals(), exec etc to work with
the name represented by that string. But you're still passing an object
to the function, not a name.


--
Steven

[greg]

Re: Finding the instance reference of an object [long and probablyboring]

Arnaud Delobelle wrote:

But in the course of conversation I might refer to
Napoleon, meaning Napoleon Bonaparte (1769 - 1821) or Napoleon III (1808
- 1873).

That's more like referring to the name 'Napoleon' in
two different namespaces. The original binding still
exists, you're just switching contexts.

My point was to get away from a model for Python which was built on its
likely implementation and to hint that we can build one using the naive
concept of 'name for a thing' instead.

I don't believe it's possible to build any complete and
correct model of Python behaviour without including some
concept equivalent to a reference.

You can talk about names written on PostIt notes and
such like, but that only gets you a short way. It doesn't
easily handle names in different namespaces, or references
that exist without simple names, e.g. list and tuple
items. Trying to repair these deficiencies only leads to
increasingly bizarre and contrived mental pictures.

On the other hand, if you explicitly include the concept
of a reference from the beginning, everything is quite
clear and consistent.

In other words, the model should be as simple as possible
but no simpler. Leaving out references makes it too
simple.

Another point I'd like to make is that there is nothing
inherently low-level about the concept of a reference.
It doesn't have to be implemented as a memory address or
any other particular machine-level thing. It's possible to
talk about Python object references in a completely
implementation-independent way.

Also, just because you don't explicitly refer to them and
manipulate them at the language level doesn't mean they
don't exist. To think otherwise is like thinking that air
doesn't exist just because you can't see it. There are
plenty of experiments which clearly indicate its existence.
Likewise, there are plenty of experiments that you can
perform with any Python interpreter that reveal the
existence of references, or something equivalent to them.

--
Greg

[greg]

Re: Finding the instance reference of an object [long and probablyboring]

Aaron Brady wrote:

I thought of another way Python's passing method could be
implemented. Parameters are passed as namespace-name pairs, and every
time a variable occurs, it's looked up in the namespace it's in. If
it's changed (concurrently) in the outer scope, a copy is made into
the inner scope. If it's changed in the inner scope, a new entry is
added there.

That sounds like a kind of copy-on-write. It's certainly not
call-by-value by any sane interpretation (contrary to your
assertion that "all calling is call-by-value").

--
Greg