Re: Object identity

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.

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.

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.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: Semantics and STL/DTL
    ... I think the reason is the semantics described sound familiar, ... "Coupling: qualitative measure of module interdependence/communication (from ... languages because the programmer can't infer any meaning from it. ...
    (comp.object)
  • Re: Semantics and STL/DTL
    ... I think the reason is the semantics described sound familiar, ... "Coupling: qualitative measure of module interdependence/communication (from ... languages because the programmer can't infer any meaning from it. ...
    (comp.programming)
  • Re: Translator design decisions
    ... languages, and a couple of semantially similar targets, it seems to ... There is a lot of compiler infrastructure to leverage, ... present in any given language that pervades the semantics and that is ... special hooks FORTRAN needed for that suite. ...
    (comp.compilers)
  • Re: Object identity
    ... programming languages. ... You have to tie down the semantics to the point where you ... Employee* e1 = new Employee; ... In each partition there exists a semaphore used for local interlocking. ...
    (comp.object)
  • Re: proof that most etymologies are only fairy-tales
    ... bear and bear (omnivorous ... I am sure there are no homonyms in any PIE reconstruction - since ... it's just about plausible from the semantics that they're the same ... which is phonetically pretty complex as languages ...
    (sci.lang)