Subject: Re: Object IDs are bad (was: Ousterhout and Tcl lost the plot with latest paper)
From: Erik Naggum <>
Date: 1997/04/26
Newsgroups: comp.lang.scheme,comp.lang.scheme.scsh,comp.lang.lisp,comp.lang.tcl,comp.lang.functional,comp.lang.c++,comp.lang.perl.misc,comp.lang.python,comp.lang.eiffel
Message-ID: <>

* Andrew Koenig
| But now suppose we want to be able to identify a specific subtree of a
| tree.  If I had gone to the trouble of creating a tree abstraction in
| C++, I could identify a particular subtree by the address of its root.
| But there's no corresponding facility in ML.  Trees are values, and
| although one can compare them for equality, there is no notion of object
| identity.

* Peter Ludemann
| Absolutely correct and correctly so.
| If two things LOOK the same, then they ARE the same.  It's called
| "referential transparency" and it's a Good Thing, as opposed to
| "pointers" which are a Bad Thing.  Why confuse your life with "object
| identity"?

it seems to me that there is some confusion between two meanings of "object
identity".  one meaning is that you can test for object identity with an
operator of some kind.  in Lisp, that's `eq'.  C has `=' when applied to
pointers.  this meaning implies that "object identity" is a value of some
sort, but in Lisp this value _is_ the object as far as the language is
concerned.  in C, the object identity _is_ a pointer, and the value is
something it points to.  this leads to the other meaning, that object
identity is a separate _type_ apart from objects, such as pointers in C.
the distinction may be useful in smoe situations, but those mostly have to
do with the allocation of objects in memory.  but regardless of how memory
is organized and used, an object is itself, and it is useful to know
whether two objects are identical, provided you can get more than one
handle on an object in the first place.  Peter Ludemann seems to think that
something other than the memory address of the object should be used for
this purpose, and that is a perfectly legitimate point, however silly.

part of the problem with pointers is that languages such as C and C++ force
you to remember the difference between a pointer and a pointed-to-value,
even though the language is supposedly strongly typed and the compiler
perfectly well knows when you get it wrong.  e.g., if you declare struct
foo *bar;, it should not be a terribly hard task for the compiler to
understand that bar.zot means the field "zot" of the structure _pointed_to_
by bar, but oddly enough, you have to write bar->zot or (*bar).zot to do
that, which is just idiotic.  such is what you get when you combine "the
compiler shouldn't be smarter than its users" with the artificial
distinction between values and pointers to them.  however, this is _not_
because of "object identity", but rather because the language conflates
object identity with the pointer type and exposes the latter to the
programmer in a way that destroys any concept of "object" and just leaves
"untyped block of memory" in its place.

I have no idea whether Peter Ludemann had a third meaning of "object
identity" in mind, and I don't know whether Andrew Koenig knows ML well
enough that it is true that ML doesn't offer object identity, but it seems
rather obvious to offer object identity if you offer composite types.  what
little I know about ML suggsts that ML _must_ offer object identity.  (how
else would you be able to talk about the constituent objects of a composite
object?)  anybody knowledgeable in ML want to explain this further?

if we work harder, will obsolescence be farther ahead or closer?