Official definition of call-by-value (Re: Finding the instance reference...)

[rurpy at yahoo.com]

[Tried multiple times to post this but Google errors
out so will try posting in two parts... this is part 1]

On Nov 14, 11:51 pm, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:
> On Fri, 14 Nov 2008 22:56:52 -0500, Terry Reedy wrote:
>
>> rurpy at yahoo.com wrote:
>>> On Nov 13, 4:53 pm, Terry Reedy wrote:
>>>> rurpy at yahoo.com wrote:
>>>>
>>>>> I have yet to see any reasonable definition of a Python value in the
>>>>> Python docs or elsewhere, despite the fact that a value is one of the
>>>>> three defining characteristics of an object, a central concept in
>>>>> Python.
>>>> I noticed too.  My try:
>>>>
>>>> The value of an object is the information that the object represents
>>>> (or that is stored with the object) that the interpreter uses to
>>>> compute the value of a new object when you use the object in an
>>>> expression.  For number objects, the number value.  For collection
>>>> objects, the objects collected. For functions, the signature and
>>>> function performed when called.
>>>>
>>>> How is that?
>>>
>>> I am starting with the idea that "value" is what we call whatever it is
>>> that is the difference between, for example, the objects int(3) and
>>> int(4).  While your definition seems to be saying something similar it
>>> does not seem very precise.
>>
>> I think necessarily so, or rather, it can only be specific for each
>> class.  In the formulation: an object has identify, class, and value,
>> class and value are separated.  Others have said that type/class is a
>> universe of possible values and operations on those values.  Each
>> instance has a particular value. 'Universe of possible values' is vague
>> until one gets specific.  For some classes, the possible values are
>> rather complex.

I will presume you read my response to Terry Reedy so
I won't repeat everything I said there here.

> I prefer another definition of object: an object *is* a value, rather
> than *has* a value. That value consists of identity, type (or class), and
> everything else of interest which is sometimes also called "value". Since
> identity is usually unimportant, and type is assumed from context, we can
> often get away with stating that the "everything else of interest" is
> *the* value.

The Python Lang. Ref. says:
  object = identity + type + value
You are defining objects as:
  object = identity + type + (object - (identity + type))
  value = object - identity = type + (object - (identity + type))

Seems to me it is easier just to give the "object - (identity + type)"
part a name, say, "value". :-)

I also question, "type is assumed from context".  To
me, type is very objective: it is the set of methods
and other attributes that define the behavior of the
object.

> I usually talk about one of the three levels of value:
>
> (1) The value of the NAME (or variable) x is the object int(3); that is,
> the thing denoted by the symbol x is the object int(3).

OK, but a name is a rather abstract concept, is it
not?  Because of Python's interpreted nature, names
can't be compiled away as in C, they need a concrete
runtime existence, but does the language definition
need to assume that?

And per innumerable previous discussions, is it not
preferable to "bind the name to an object" sidestepping
any need for "value" in this context?

> (2) The value of the OBJECT int(3) is the specific concrete instantiation
> that makes it the thing that it is rather than another thing (a
> complicated way of saying that the value of an object is itself); that
> is, the thing denoted by the symbol int(3) is some specific byte pattern
> in memory which causes that object to be int(3) rather than some other
> object.

I don't see how saying "the value of an object is
itself" is particularly useful.  We already have a
word for what an object is, it is "object". :-)
The point of the word "value" is to describe, in
a general way, without defining implementation
details, what you describe as "some specific byte
pattern in memory which causes that object to be
int(3) rather than some other object" and does not
mix in other bit-pattern differences, such as
differences in type which are not relevant to what
we intuitively think of as "value".

> To put it another way, the value of that object is whatever properties of
> the object distinguish it from any other the whole number 1.

This is saying something different, that the value
of an object depends on how it's type relates to
some non-programming-language concept ("whole numbers"
in this case) that the object attempts to model.

> Since
> identity is (usually) unimportant for distinguishing one object from
> another (we usually care whether x==y, not whether x is y) the identity
> is not part of the value.

The result of x==y depends solely on the behavior (methods)
of x.  (To be anal, the behavior of x might be to delegate
calculating the result to y).  That behavior (if reasonable)
will take into consideration the "value"s of x and y.  This
seems to imply that "value" is something more specific
than the totality of the x and y objects.

> We're generally indifferent to the serial
> number on our ten dollar bills: any note is (usually) as good as any
> other note. But sometimes identity is important, and in some specific
> contexts I'd be happy to say that the value of a symbol must include the
> identity of the object.

What you or I think is important in a calculation
need not have a bearing on an object's value.  id()
does not need to consider that identity is part of
an object's value -- its programmer needed merely
use identity if that's what was needed, while it's
argument goes on having whatever value it has.

> (3) But at another level, the value of the object int(3) is the abstract
> integer three. This is the only level at which I'm happy to talk about
> objects (as opposed to names) "having" a value: "object int(3) has the
> value three".

As above, where you referred to "the whole number 1",
this seems problematic.  What one is doing is mapping
int's to the mathematical concept of integers and using
the equivalence of integers to decide the equivalence
of ints.  This is fine if you are relating the behavior
of your program to real-world mathematics.  But in
some cases the mapping may not be so clear, nor may
there be universal agreement about what is equivalence
in the real-world concept, so it seems shaky to pin
a fundamental defining concept of Python objects to
this.

Is the value of float(1.0/3.0) the same as
float(.3333333333333333)?  Mathematics says no, but
Python (at least on my machine) says yes.  (At least
if you accept that the "==" operation is written to
compare values.)

>>> How would I use your definition to answer the following questions?
>>>
>>> * How does an object get a value?
>>
>> A Python interpreter, human or electronic, creates objects with values
>> as directed by Python code.  How it does so is its private secret ;-).
>> The directive code includes literals, expressions, and some statements.
>
> I would answer that the object *is* the value, but with the proviso that
> we usually don't care about identity:
>
>>>> x = 19990
>>>> y = 19990
>>>> x == y
> True
>>>> x is y
> False
>
> I'm happy to say that the value of x and the value of y are the same,
> even though they have different identities. But context is important:
> there are times were I would want to wrap identity under the umbrella of
> value. See below.

So you would say that a and b have different values below?

class My_int(int):
    def __init__(self): self.foo = None
a = int(3)
b = My_int(3)

How can one have an objective definition
of "value" if it depends on context?

[continued...]