[gclist] John Carter's one-place/one-object approach

[Eliot Moss]

There's a major problem with your proposal, from my point of view. All you
have done is push the gc problem off a level and back into the programmer's
lap. To see this, suppose I have a container into which I start inserting
objects, and I allow objects in the container to "name" other objects in the
container, using your integer indexes. How do I know when a specific object in
the container is no longer needed? That is, how do I avoid the run-time error
"no object at this index" while still getting rid of objects that will no
longer be used?

In fact, you have made the problem _harder_ than it is in other languages,
since the pointer type in most other language is distinguished from integers,
whereas you make no such distinction. Hence there is no way to know which
stored integers represent index values (and into which containers), or to
prevent arbitrary integer arithmetic from creating values and then trying to
use them. It seems my only recourse is explicit deletion (except you have
renamed it to "copying the object out of the container").

If you intended to suggest more refined pointer types, that include a scope
(container), then you might have some advantages, though that idea has been
proposed before (Euclid had that, as I recall), though I would agree that it
has never been followed through enough to completely understand its advantages
and weaknesses. It would appear that having to keep track of the (conceptual)
place where an object is introduces more detail, and more opportunity for
bugs, into programs.

Well, I could elaborate this, but think I'll give others their shot at
responding.

Regards --						Eliot Moss

J. Eliot B. Moss, Associate Professor
Computer Science Department, LGRC          (413) 545-4206
University of Massachusetts                (413) 545-1249 (fax)
Box 34610                                  moss@cs.umass.edu (email)
Amherst MA 01003-4610