Subject: Re: C++ briar patch (Was: Object IDs are bad)
From: Erik Naggum <>
Date: 1997/05/31
Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.lang.misc,comp.lang.functional,comp.lang.c++
Message-ID: <>

* Peter da Silva
| For example, people keep telling me that other objects in Lisp also act
| as pointers. I've never denied it, I just brought up CONS cells because
| they're the best example of a data structure that's uniformly available
| in lisps that can be used as "an opaque reference" (avoiding using the P
| word here).

dragging in the cons cell is like dragging a red herring across your path
to confuse anybody who might be trying to follow your point.

the cons cell holds two Lisp objects.  any Lisp variable can hold one Lisp
object.  what's the big deal with cons cells that isn't true of variables?

the general machine representation of a Lisp object is a machine word (in
all implementations I know and have heard about), which, if it can hold the
value, holds the value, otherwise it holds the machine address of the value
plus some administrative information like type tags.  the typical values
that fit in a machine word are small integers (fixnums) and characters.
other values have to be "boxed", i.e., put in some other memory and a
reference (pointer!) to that memory passed around as the value.  `eq'
compares the machine representation of these objects.  assignment copies
the machine representation of the Lisp object, which is this pointer or
value-that-fits-in-a-machine-word.  with the exception of the values that
fit in a machine word, this has the traditional C pointer semantics.   (I
have already granted Peter this point several times over.  please get it!)

it's worth noting that (cons 1 2) yields a pointer (!) to a cons cell that
contains two fixnums, not two pointers.  where this pointer concept differs
from C's pointer concept is that you can't make a new pointer to a
different part of memory by doing arithmetic on an existing pointer, you
can't obtain the address of an object that doesn't already have a pointer
to it, and you can't treat the pointed-to object and the object as two
distinct types or values.

somebody requested a definition.  the defining property of a pointer qua
language construct is that the language supports a type that is a pointer
to another of its supported types.  Common Lisp does not have this property
for any of its types.  C does have it for all of its types.  (however, some
Lisps support locatives, which have a type that is a pointer to another
type.)  as far as language semantics goes, Lisp does _not_ have pointers.

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