Subject: Re: Object IDs are bad (was: Ousterhout and Tcl lost the plot with latest paper) From: Erik Naggum <erik@naggum.no> 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: <3071056971024295@naggum.no> * 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? #\Erik -- if we work harder, will obsolescence be farther ahead or closer?