Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

IDENTITY-OF function

17 views
Skip to first unread message

Will Fitzgerald

unread,
Feb 13, 2002, 9:49:03 AM2/13/02
to
For various reasons -- mostly having to do with serializing Lisp data
or remote procedure calls -- it seems useful to have an 'identity-of'
function which returns a (unique) identity for a Lisp object. The only
place I know of in the CL spec that mentions an object's identity is
the PRINT-UNREADABLE-OBJECT function, which states (about the
:IDENTITY keyword):

If identity is true, the output from forms is followed by a space
character and a representation of the object's identity, typically a
storage address.

Questions:

1. Are there implementation specific functions that do what I want?

2. Do you think the following (which returns the identity as a string)
is reasonably portable?

(defun identity-of (object)
(let ((string
(with-output-to-string (str)
(print-unreadable-object (object str :type NIL :identity T)))))
(subseq string
(1+ (position #\Space string))
(position-if #'(lambda (ch)
(and (graphic-char-p ch)
(not (char= ch #\Space))))
string
:from-end t
:start (1- (length string))))))

Erik Naggum

unread,
Feb 13, 2002, 12:24:16 PM2/13/02
to
* Will Fitzgerald

| For various reasons -- mostly having to do with serializing Lisp data or
| remote procedure calls -- it seems useful to have an 'identity-of'
| function which returns a (unique) identity for a Lisp object.

The Lisp object _is_ its identity, so identity-of is already implemented:
it is the function identity.

| If identity is true, the output from forms is followed by a space
| character and a representation of the object's identity, typically a
| storage address.

That is only (intended to be) useful for debugging purposes.

| 1. Are there implementation specific functions that do what I want?

Well, you can get the address of a Lisp object in most implementations,
but what good will it do? Even when you use print-unreadable-object,
there is no guarantee that the identity will actually remain the same
over any period of time. Most Common Lisp implementations utilize a
memory management system that can move objects around in memory.

| 2. Do you think the following (which returns the identity as a string)
| is reasonably portable?

If you want portable, use an eq hashtable that maps to a unique numeric
object identifier that you request for each object. Note that this
entangles you in the annoying object ownership protocol business. You
may get around this problem with a weak key. A bidirectional hashtable
does not exist, so you may have to use another with the identifier as key
and a weak value, instead.

If you need this for RPC, what good is the "identity" if it is not
understood on the other side of the communication? I must be missing
something important here.

///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.

Barry Margolin

unread,
Feb 13, 2002, 3:04:34 PM2/13/02
to
In article <32226098...@naggum.net>, Erik Naggum <er...@naggum.net> wrote:
> If you need this for RPC, what good is the "identity" if it is not
> understood on the other side of the communication? I must be missing
> something important here.

I suspect the intent is that you send something to the remote end, it
treats it as an opaque reference, and may later send it back to you. You
can then use that data to find the original object.

The right solution for this is probably to make up your own unique
identifier of some kind. You can put all the objects you care about in an
array, and use the array index as the unique id.

As Erik pointed out, using the memory address that PRINT-UNREADABLE-OBJECT
prints is unreliable, since the object may move as a result of GC. If you
use the above idea, the unique id's are guaranteed to be unique and stable
(as long as you're running in the same Lisp image).

Another possibility is that he's sending the identifier along with the
serialized contents of the object, and it's needed to distinguish objects
that look identical otherwise. The PRINT-UNREADABLE-OBJECT idea could
screw up if there's a GC between two uses -- two different objects could
have the same address if one gets moved to where the other one used to be.

--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

Marco Antoniotti

unread,
Feb 13, 2002, 3:51:22 PM2/13/02
to

Barry Margolin <bar...@genuity.net> writes:

> In article <32226098...@naggum.net>, Erik Naggum <er...@naggum.net> wrote:
> > If you need this for RPC, what good is the "identity" if it is not
> > understood on the other side of the communication? I must be missing
> > something important here.
>
> I suspect the intent is that you send something to the remote end, it
> treats it as an opaque reference, and may later send it back to you. You
> can then use that data to find the original object.

For this sort of things, a look into the CMUCL WIRE package may be
useful.

As an aside, the SAVE-OBJECT package (available in the CMU
AI.Repository) already does some serialization for you.

Cheers

--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.

Will Fitzgerald

unread,
Feb 13, 2002, 9:36:33 PM2/13/02
to
Thanks to all for your comments. I hadn't considered the GC problem in
particular.

For what it's worth, what I am doing is sending representations of lists
over tcp, and it can be the case that one list such sent is part of a list
sent later. In this case, I want to send some kind of unique id. But (as
Erik Naggum and Barry Margolin point out), a generated unique id will work
fine.

Will Fitzgerald


0 new messages