Is 'everything' a refrence or isn't it?

[Bengt Richter]

On Mon, 09 Jan 2006 07:40:18 -0000, "Donn Cave" <donn at drizzle.com> wrote:

>Quoth rurpy at yahoo.com:
>| Fredrik Lundh wrote:
>| ...snip...
>| > afaik, the Python Language Reference never defines the word "reference".
>| > It carefully defines words like "object" and "value", though, and terms like
>| > "call by object" or "call by object reference" are perfectly understandable
>| > if you use the words as they are defined in the language reference.
>|
>| It (sec. 3.1, "Objects, values and types") is not what I would
>| call a good definition .  About values it says only
>|
>| - that they are something that all objects have.
>| - they can be mutable or immutable.
>|
>| It then has a few sentences about mutability, so after reading
>| it you will know that, whatever a value is, it can be changed
>| for some objects but not others.  But what exactly it is that is
>| being changed is still a mystery.
>| Further down it talks about container objects "containing"
>| references to other objects and of those being part of it's
>| value.  Part?  What does it mean to contain?  Can one
>| determine from reading this, if an attribute value is part
>| of the object's value?  (I couldn't).
>|
>| On my list on Python Doc problems that need fixing, is
>| "defintion of object values" and it has been on there
>| for nearly a year.
>
>So you've had time to think about how you would define value, in a
>few words.  Any ideas?
>
>I find the topic difficult, myself.  I think you really have to apply
>some context to the question, so there may not be any satisfactory
>definition for the language reference.
>
>But maybe it would be simple with the right focus.  If we could somehow
>define value, how would that help?  I mean, presumably we need to
>understand all this stuff because we want to write some software, and
>if we dive in without understanding, our attempts will be plagued with
>conceptual errors.  Is there something about value in particular that
>seems to be a problem here?  ``No, you idiot, that's not a value -
>THIS is a value!''
>
IMO the problem is that our intuitive notion of value is ususally really of
an abstract value, like an integer value or a real or maybe a member of a finite
abstract set. But in programming we are always dealing with various concrete
representations of values, not values themselves. To get to a value, you have
to interpret the representation. To perform abstract operations, you have to
manipulate concrete representations, and guarantee that the resulting representations
really do represent the abstract results of the abstract operation.

People are so used to interpreting representations that they do it unconsciously.
Mostly the metonymic use of representations in discussing abstractions is a
taken-for-granted short cut for avoiding tiresome pedantry, but sometimes, I believe,
it lies at the heart of difficulties such as in trying to define value.

IMO the first step in defining "value" should be to declare that it always refers
to some abstract value, which is always an interpretation of some concrete representation.

I suspect that describing things in terms of abstract graphs and their transformations
would be useful. E.g., starting with python's objects (in the abstract) as nodes,
and "references" as directed arcs.

More on this later, perhaps, but I have to go now ...

Regards,
Bengt Richter