Re: Object identity


Dmitry A. Kazakov wrote:
On 29 Jun 2006 19:03:17 -0700, David Barrett-Lennard wrote:

Dmitry A. Kazakov wrote:
On 29 Jun 2006 10:04:54 -0700, David Barrett-Lennard wrote:

Bruno Desthuilliers wrote:

In "pure" 00PLs, this distinction does not exist. Now you have types
with a very straightforward "value" semantic (ie integers, strings etc)
- which in some languages happens to be immutable objects - types with a
more complex "value" semantic (records-like types) but for which (total
or partial) structural equality can still make sens, and types for which
a "value" semantic would be harder to define, like ie class objects or
function objects - in this last case, "value" equality could be defined
as "given same inputs, produces same ouptputs", but this would be nearly
impossible to test in practice AFAICT, at least in most current
programming languages.

I can think of some object types where "value" equality testing (as
distinct from identity testing) doesn't seem to make sense at all.

To me identity is a value of some possibly different type, of which it is
known that these values are comparable (exists =, transitive, reflexive,
commutative). Quite simple, IMO.

It is necessary for object identity to have those features, but not
sufficient. You have to tie down the semantics to the point where you
can predict how source code will behave. Eg

Employee* e1 = new Employee;
Employee* e2 = new Employee;
e1->SetName("Einstein");
e2->SetName("Godel");
assert(e1->GetName() == "Einstein");
assert(e2->GetName() == "Godel");

We know those assertions won't fail because there is a binding of
identity to the instance. That's part of the formalism of OO.

No. There is nothing binding here. There are *two* identities:

1. Referential identity. The identity function of is "&". (Pointers are
comparable)

2. An identity induced by the function "GetName". (Strings are comparable)

Now, forall x,y &x = &y <=> GetName(x) = GetName(y) is not the semantics of
identity. They aren't required to be "identical." It is just a behavior,
the program designer might wish to have. If he does, then it is his
responsibility to ensure this.

I was pointing out that merely saying that identity must be an
equivalence relation doesn't capture all the semantics. Being an
equivalence relation is necessary but not sufficient. Perhaps I have
misunderstood you?


Even true names aren't binding:

Port := 1;
if Port = 1 then

You might never get here, because Port is mapped onto a hardware output
register. Reading such register could have a quite different semantics than
reading normal memory.

I wonder if there are also some object types for which there are
multiple candidates for value semantics.

I think it would be wrong to mix semantics [the value of an object] with an
ability to check it. Comparing values might be incomputable, in strict
sense. Because values are outside the language.

Yes.

I doubt whether it's always reasonable to characterise an object by its
"value", as if that can exist and be interpreted independently of the
object. What is the "value" of a critical section? Is it meaningful
to talk about its state (ie which identifies whether it is currently
locked, by what thread and how many times by that thread) outside the
context of the executing process? Clearly not. When I think of
values, in my mind I think of an interpretation map to some entity
outside the computer space, such as when a 32 bit int represents a
number.

Ok

I have trouble thinking of a critical section this way.
What's the entity that it represents?

Why? It is especially makes sense for things like critical sections,
hardware random generators, clocks etc, because their states are
fundamentally incomputable, i.e. you cannot describe their behavior in a
Turing-complete way.

This is interesting because paradoxically that's what I mean! We
*must* treat a critical section as an object-type. It doesn't make
sense to treat it as a value-type (which implies it maps under
interpretation to some entity outside the computing space). By
treating it as an object-type we are saved from the need to interpret
its state. Instead we are allowed to treat it as an object - a black
box that encapsulates identity, state and behaviour within a state
machine defined in the computing space.

Now it is always possible to define an isomorphism from a state machine
expressed at the level of instances in memory, to an equivalent,
abstract state machine. But what is the value in that? When
mathematicians have isomorphisms they (al least informally) blur the
distinction. That's why it seems rather silly to me to say that
instances of object-types aren't objects.

It seems easier to just say
that it is what it is - an instance in memory that has identity, state
and behaviour.

The behavior of memory is not one of the critical section or, say, clock,
represented as a counter of ticks. You have a postulated mapping between
memory states and them. If the behavior of clock, suddenly changed, the
program would have to way to detect it, provided that there is no other
time sources. This is why all simulations can work.


Cheers,
David Barrett-Lennard

.

Relevant Pages

  • Re: Object identity
    ... associating identity with the instance in memory as well as the button ... A value-type is any type that is not an object type. ... Therefore pointers to value-type instances ... multiple candidates for value semantics. ...
    (comp.object)
  • Re: Object identity
    ... programming languages. ... Employee* e1 = new Employee; ... Reading such register could have a quite different semantics than ... reading normal memory. ...
    (comp.object)
  • Re: is laziness leakier?
    ... Strict vs non-strict is an issue of semantics. ... worry about low-level things like memory management. ... Abstractions": All non-trivial abstractions, to some degree, are leaky ... beyond the language primitives and a handful of core classes, ...
    (comp.lang.functional)
  • Re: Cohens paper on byte order
    ... > one pulls a byte somewhere from the memory into, say, ... > a variable in the program's storage space, ... > abstract byte of the AES follows. ... to the semantics of the document, no more, nor less. ...
    (sci.crypt)
  • Re: how is Haskell not robust?
    ... without knowing the context in which it's used. ... Uses Omemory, no matter which prime you pick by index. ... informal semantics you described above). ... second print I still get 23 GiB heap allocation. ...
    (comp.lang.functional)