Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use compiler-native IDs instead of our id/new-id? #2991

Open
aartaka opened this issue May 29, 2023 · 8 comments
Open

Use compiler-native IDs instead of our id/new-id? #2991

aartaka opened this issue May 29, 2023 · 8 comments

Comments

@aartaka
Copy link
Contributor

aartaka commented May 29, 2023

Our ID indexes objects we create, but indexing requires either:

  • Adding an id slot to an object.
  • Or storing the ID-object pair somewhere else.

Both are cumbersome. What if we had some Lisp-native way to generate object IDs without any work on our side? Like...

  • print-unreadable-object's :identity option
  • or sxhash!

Most implementations use some kind of implementation-internal object ID fetching for unreadable objects, and most have Lisp APIs for getting this ID reliably. Here's what I've been able to hack up for SBCL, CCL, ECL, and ABCL:

(defun id (object)
  #+sbcl (sb-kernel::get-lisp-obj-address object)
  #+ccl (ccl::%address-of object)
  #+ecl (si:pointer object)
  #+abcl (system::identity-hash-code object)
  #+clisp (system::address-of object)
  #+gcl (system:address object)
  #+allegro (excl:lispval-to-address object)
  #-(or sbcl ccl ecl abcl clisp gcl allegro) (sxhash object))

For all the other implementations there's always sxhash which has nice properties (equal objects have the same sxhash), but IDs are even better and come from the reliable compiler internals and are guaranteed to never collide for different objects (which most hash functions occasionally do).

So, shall we go down that road?

EDIT: Update for CLISP, GCL, and Allegro.
EDIT: Fix a typo.

@aadcg
Copy link
Member

aadcg commented May 29, 2023

Sounds interesting to me.

@Ambrevar
Copy link
Member

Very smart, I like it! :)

@aartaka
Copy link
Contributor Author

aartaka commented May 30, 2023

Updated function for some more implementations I've tested:

(defun id (object)
  #+sbcl (sb-kernel::get-lisp-obj-address object)
  #+ccl (ccl::%address-of object)
  #+ecl (si:pointer object)
  #+abcl (system::identity-hash-code object)
  #+clisp (system::address-of object)
  #+gcl (system:address object)
  #-(or sbcl ccl ecl abcl clisp gcl) (sxhash object))

@Ambrevar
Copy link
Member

Nonguix has AllegroCL if you feel like testing it :)

@aartaka
Copy link
Contributor Author

aartaka commented May 30, 2023

Nonguix has AllegroCL if you feel like testing it :)

The license has expired and I've sent a patch to Nonguix to fix it :P

@Ambrevar
Copy link
Member

Ambrevar commented Jun 6, 2023

Done!

@aartaka aartaka mentioned this issue Sep 13, 2023
7 tasks
@jmercouris
Copy link
Member

I don't see the benefit here. In fact if we serialize an object where we have the id in a slot, that id will be persisted. With this method, it would not, no?

@aartaka
Copy link
Contributor Author

aartaka commented Nov 29, 2023

I don't see the benefit here. In fact if we serialize an object where we have the id in a slot, that id will be persisted. With this method, it would not, no?

Yes, but we can compile the data into .FASL-s to preserve the object itself, for example.

EDIT: we

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants