GNU bug report logs - #68244
hash-table improvements

Previous Next

Package: emacs;

Reported by: Mattias Engdegård <mattias.engdegard <at> gmail.com>

Date: Thu, 4 Jan 2024 16:29:02 UTC

Severity: wishlist

Full log


Message #142 received at 68244 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Dmitry Gutov <dmitry <at> gutov.dev>, Eli Zaretskii <eliz <at> gnu.org>,
 68244 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#68244: hash-table improvements
Date: Thu, 8 Feb 2024 15:42:45 +0100
8 feb. 2024 kl. 15.19 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:

> For me, the more important aspect of obarrays is that we should have
> a separate obarray type

Oh yes. This is necessary for automatic growth if nothing else.

> Of course, we'd still have to *also* accept plain vectors, sadly.

In some contexts such as `try-complete` perhaps, but I don't think we're saddled with it forever in places that actually use an obarray (like `intern`).

>  we can do something much simpler: vectors are accepted by
> simply storing in the first field a reference to the actual obarray
> object, so there's no need to play any games and/or share representation
> between vectors and obarray.

Why is that simpler than having `intern` accept both obarray objects and plain vectors, during a transitional period?





This bug report was last modified 1 year and 146 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.