GNU bug report logs - #68244
hash-table improvements

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
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: Wed, 14 Feb 2024 08:05:12 -0500

>>> With Stefan's suggestion, if I understood it right,
>>> we'd have `obarray-make` return (vector 0).
>> I did not suggest such a thing.
> Sorry, didn't mean to misrepresent. I should have said that it is one way of
> implementing `obarray-make` if compatibility with vector-assuming code
> really is a serious concern.

BTW, my idea adjusted for the kind of compatibility you're after would
have been to define `obarray-make` as (vector (internal-make-real-obarray))

>> I think it's worth introducing a bit of incompatibility, for the benefit
>> of a cleaner API.  Such incompatibility should be very easy to fix while
>> still maintaining compatibility with old Emacsen (at least back to
>> Emacs-25, where the `obarray-make` and `obarrayp` were introduced).
> I'm all for it but those obarray functions weren't mentioned in NEWS at the
> time nor in the manual (which even today recommends, even mandates, use of
> make-vector) so perhaps we need a bridge?

You might be right.  I guess time will tell :-)


        Stefan

Previous Next

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