From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 09 Oct 2017 00:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 28753@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.150750876811682 (code B ref -1); Mon, 09 Oct 2017 00:27:02 +0000 Received: (at submit) by debbugs.gnu.org; 9 Oct 2017 00:26:08 +0000 Received: from localhost ([127.0.0.1]:56889 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e1LtY-00032M-8H for submit@debbugs.gnu.org; Sun, 08 Oct 2017 20:26:08 -0400 Received: from eggs.gnu.org ([208.118.235.92]:55215) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e1LtW-00031s-74 for submit@debbugs.gnu.org; Sun, 08 Oct 2017 20:26:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e1LtQ-0002C9-5S for submit@debbugs.gnu.org; Sun, 08 Oct 2017 20:26:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:58299) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e1LtQ-0002By-1n for submit@debbugs.gnu.org; Sun, 08 Oct 2017 20:26:00 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46181) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e1LtO-00036e-VD for bug-gnu-emacs@gnu.org; Sun, 08 Oct 2017 20:25:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e1LtK-00027S-0P for bug-gnu-emacs@gnu.org; Sun, 08 Oct 2017 20:25:58 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:37080) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e1LtJ-00026a-NS for bug-gnu-emacs@gnu.org; Sun, 08 Oct 2017 20:25:53 -0400 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v990Pp2B003291 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 9 Oct 2017 00:25:51 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v990PoHd008591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 9 Oct 2017 00:25:51 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v990Pnte014528 for ; Mon, 9 Oct 2017 00:25:49 GMT MIME-Version: 1.0 Message-ID: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> Date: Sun, 8 Oct 2017 17:25:47 -0700 (PDT) From: Drew Adams X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4588.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) Dunno whether functions like these might be useful. I use something similar. If you think they're useful, consider adding them. (cl-defun alist-to-hash-table (alist &optional use-last-p &key (test 'eql) weakness (size 65) (rehash-size 1.5) (rehash-threshold 0.= 8)) "Create and return a hash table created from ALIST. By default, if the same alist key is used in more than one alist entry then only the first entry is used for the hash table. Non-nil USE-LAST-P means override this to use only the last entry for a given key. See `make-hash-table' for the keyword arguments you can use and their default values." (let ((ht (make-hash-table :test test :weakness weakness :size size :rehash-size rehash-size :rehash-threshold re= hash-threshold)) key val) (dolist (key.val alist) (setq key (car key.val) val (cdr key.val)) (when (or use-last-p (not (gethash key ht))) (puthash key val ht))) ht)) (defun hash-table-to-alist (hash-table) "Create and return an alist created from HASH-TABLE. The order of alist entries is the same as the order of hash-table entries (which normally is the order in which the entries were added to the table)." (let ((al ())) (maphash (lambda (key val) (push (cons key val) al)) hash-table) (nreverse al))) In GNU Emacs 25.3.1 (x86_64-w64-mingw32) of 2017-09-26 Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --without-dbus --without-compress-install 'CFLAGS=3D-O2 -static -g3' PKG_CONFIG_PATH=3D/mingw64/lib/pkgconfig' From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 09 Oct 2017 13:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: 28753@debbugs.gnu.org Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.15075552619161 (code B ref 28753); Mon, 09 Oct 2017 13:22:02 +0000 Received: (at 28753) by debbugs.gnu.org; 9 Oct 2017 13:21:01 +0000 Received: from localhost ([127.0.0.1]:57319 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e1XzR-0002Nd-9n for submit@debbugs.gnu.org; Mon, 09 Oct 2017 09:21:01 -0400 Received: from mout.web.de ([217.72.192.78]:52545) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e1XzP-0002NC-HY for 28753@debbugs.gnu.org; Mon, 09 Oct 2017 09:20:59 -0400 Received: from drachen.dragon ([88.67.74.137]) by smtp.web.de (mrweb102 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MbhRh-1dkhQT2Eo1-00J65r; Mon, 09 Oct 2017 15:20:48 +0200 From: Michael Heerdegen References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> Date: Mon, 09 Oct 2017 15:20:47 +0200 In-Reply-To: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> (Drew Adams's message of "Sun, 8 Oct 2017 17:25:47 -0700 (PDT)") Message-ID: <87r2uce9u8.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:FFA1yeujId9g70B9Vb1Bkc2h6FE63U47//d+O8+JlXcMZQslkRx eOX+3SHgqdYpLkspsfkBesZAhQfOSKv6biNMwL+zUe5I+OgNk9EsMzynjwYPuN3wF1B6hyG 2a6uZR+Uanrmhvk5PGIWVS8ipVDoIGzFbEA0aneglwv/DIoCrz+1UL56AZJYvDqfphw/lf1 FamTHRtIAN1A027Z3GHVw== X-UI-Out-Filterresults: notjunk:1;V01:K0:JreZcVPBnmo=:g0F97B6qIp/vRmBS823pKk lHuuOq49wmfO+pQTaeJPvU2GNPAXVhQWZ2urwuk5hEfVaEaW8JqDIgRdX2eTYrmichvJBzle1 k3WpZagO8Ha9/uBgsI6pWc5kOeRTOAHYrA6m9v0k19g1rt68dDmWGLYmH0CA1c0ruo4zWkuXi Io39heQ9yzqPHtERek28jqM/WTgCxuuMsv1gqKljwgrGTDwmP7wjPEYde8XsedCUzAiG9T7Ie uIm+ybZ1aVoJoTS3P6dBPrQHfyo00q3nWW6TpwKJhcgoSrJt4CUMLDlPHdS+l7OQe7p43u847 KDbXxZ4IbeiBZwYUOuX+xQDe6OOHKBNhNuRurHLPl3UQTN34lXwq6E+QUjbdJXbMWm+Im+2AW hphurOQoP+mL1BR8cXQGJaea31FgJPZPHUpLV53zK9wjlYnnohIRElrc3ZO89mqki2SeQpZuv /8+o6hFq7vX4ktycQHZsBu/myJEU97udbyP3Bfu09iqyEGQ7ooEsgOJuzbBNp9GZiCfXqG5fd BgqjnMwo3CSAalt8BKXz+2n64pj/sZEh2S3IbVl6R/5sYd6Jq5FEJ8uo/AJjsPE8CZXgFA4Km rUQSL4im6JCBZqfJgK7GtzytEyl9OH/dIb0RqFvUTe46J4KSFrSA6ht81MddZ09L5NAkogmQ2 +Bfh5/fnFw270FR62DT0V7U6bfz/T+TWss9VA43dsIlZKPATSR5G+sze+VMtpe5KfK6Jo5f8/ vASPeeVxz9pb1t5vLdV7/qxBj1MLuSulBr44tvNB1TBG5/FMWWDzLCTXsYk4RId6G3B2OTEdI 3lrelftDlQH9fWyz5eRk9EgBi0F0bULAViNphZXNLIo7NOQ2qc= X-Spam-Score: -3.5 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.5 (---) Drew Adams writes: > Dunno whether functions like these might be useful. I use something > similar. If you think they're useful, consider adding them. I think something very similar is provided by map.el: `map-into'. Michael. From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 09 Oct 2017 14:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Michael Heerdegen Cc: 28753@debbugs.gnu.org Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.150755830815582 (code B ref 28753); Mon, 09 Oct 2017 14:12:01 +0000 Received: (at 28753) by debbugs.gnu.org; 9 Oct 2017 14:11:48 +0000 Received: from localhost ([127.0.0.1]:58407 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e1Yma-00043G-IP for submit@debbugs.gnu.org; Mon, 09 Oct 2017 10:11:48 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:41623) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e1YmX-000430-Ql for 28753@debbugs.gnu.org; Mon, 09 Oct 2017 10:11:46 -0400 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v99EBd43006508 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 9 Oct 2017 14:11:39 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v99EBc0J017562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 9 Oct 2017 14:11:39 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v99EBbeX025810; Mon, 9 Oct 2017 14:11:38 GMT MIME-Version: 1.0 Message-ID: Date: Mon, 9 Oct 2017 07:11:37 -0700 (PDT) From: Drew Adams References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> <87r2uce9u8.fsf@web.de> In-Reply-To: <87r2uce9u8.fsf@web.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4588.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0021.oracle.com [156.151.31.71] X-Spam-Score: -5.1 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.1 (-----) > > Dunno whether functions like these might be useful. I use something > > similar. If you think they're useful, consider adding them. >=20 > I think something very similar is provided by map.el: `map-into'. Good to know. Thx. From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Oct 2017 16:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Michael Heerdegen Cc: 28753@debbugs.gnu.org Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.150774018030108 (code B ref 28753); Wed, 11 Oct 2017 16:43:01 +0000 Received: (at 28753) by debbugs.gnu.org; 11 Oct 2017 16:43:00 +0000 Received: from localhost ([127.0.0.1]:34424 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2K5z-0007pY-Qt for submit@debbugs.gnu.org; Wed, 11 Oct 2017 12:43:00 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:20837) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2K5y-0007pK-BJ for 28753@debbugs.gnu.org; Wed, 11 Oct 2017 12:42:58 -0400 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v9BGgpOO026873 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 Oct 2017 16:42:52 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v9BGgoCt020966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 11 Oct 2017 16:42:51 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v9BGgn6H018065; Wed, 11 Oct 2017 16:42:49 GMT MIME-Version: 1.0 Message-ID: <3da0f75d-6000-410d-9e0b-ea293677b5ed@default> Date: Wed, 11 Oct 2017 09:42:47 -0700 (PDT) From: Drew Adams References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> <87r2uce9u8.fsf@web.de> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4588.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-Spam-Score: -5.1 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.1 (-----) > > > Dunno whether functions like these might be useful. I use something > > > similar. If you think they're useful, consider adding them. > > > > I think something very similar is provided by map.el: `map-into'. >=20 > Good to know. Thx. Actually, going from alist to hash table doesn't look so useful with `map-into'. A caller should be able to specify the hash-table parameters (features), such as :test. `map-into' should probably accept additional, keyword args, which would be passed to `map--into-hash-table'. I imagine that `map-into' is intended to be extended to more than alists and hash tables eventually. Otherwise, dedicated functions for those two types, such as what I suggested, would make as much (or more) sense. Whether or not it will be so extended, it would be good for `map-into' to accept additional args that would be passed to the appropriate type-conversion helper functions. If we just allowed an &rest ARGS parameter, that would handle any types that might want to deal with additional args. But that would be less convenient than using keyword args for a hash table. We could I guess just pass ARGS along but define the helper function (e.g. `map--into-hash-table') using `cl-defun' with appropriate keyword args. IOW, at the `map-into' level nothing would be specified about ARGS, but each conversion helper could define what kinds of args it accepts. (There's also `&allow-other-keys', but probably it doesn't make much sense for `map-into' to define any keyword args.) In that case, the helper function should not be "internal", and the use of `make-hash-table' keyword args should be mentioned in its doc string. Although simple lookup in an Elisp alist typically uses only `assoc' or `assq' (or `rassoc' or `rassq'), a program that _uses_ an alist might well make use of a different equality test for its elements. It need not be limited to testing membership using `assoc' or `assq'. So while the alist to be converted to a hash table might not, itself, have any fancy notion of a :test function, the appropriate "equivalent" hash table in some context might well need to define a particular :test. This is why it makes sense to allow conversion to a hash table to give programmers an ability to specify :test (and other hash-table features). Note too that in Common Lisp `assoc' takes a :test arg. `map-into' is designed for alists that use `cl-assoc' as much as for those that use `assoc'. Unlike a hash table, however, an alist doesn't itself record ir require any particular :test function, so `map-into' can't transfer a hash-table :test to an alist that it produces from a hash table. So the existing `map-into' for conversion to an alist is good enough. From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Nicolas Petton Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Oct 2017 13:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Michael Heerdegen , Drew Adams Cc: 28753@debbugs.gnu.org Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.150781486428430 (code B ref 28753); Thu, 12 Oct 2017 13:28:01 +0000 Received: (at 28753) by debbugs.gnu.org; 12 Oct 2017 13:27:44 +0000 Received: from localhost ([127.0.0.1]:35017 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2dWa-0007OU-B2 for submit@debbugs.gnu.org; Thu, 12 Oct 2017 09:27:44 -0400 Received: from petton.fr ([89.234.186.68]:58424) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2dWX-0007OC-S5 for 28753@debbugs.gnu.org; Thu, 12 Oct 2017 09:27:42 -0400 From: Nicolas Petton In-Reply-To: <87wp4038m0.fsf@web.de> References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> <87r2uce9u8.fsf@web.de> <3da0f75d-6000-410d-9e0b-ea293677b5ed@default> <87wp4038m0.fsf@web.de> Date: Thu, 12 Oct 2017 15:27:34 +0200 Message-ID: <87r2u8sdh5.fsf@petton.fr> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petton.fr; s=mail; t=1507814855; bh=Dve9UYrsPPFo8IP3e85B+IyjZ5sq7i+7Sv0oVL9SwQA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:MIME-Version:Content-Type; b=UvFudFxnO/EX3qOhxmbIFUMGOALWVO7XJ2YPwnvNSZMe/nYcbajKKfy+DyswMY/wQ6ydPegaJ6uhYOPQCvDp0UjRcbJz/r8ZbGDmL+5J89N/WHuno1PEfErEN/5jSCYrp4ZuTqOaN7UZEM7hD4PSafVxhzbOHPyLUmMZxhbQARs= X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) --=-=-= Content-Type: text/plain Michael Heerdegen writes: >> Actually, going from alist to hash table doesn't look so >> useful with `map-into'. A caller should be able to specify >> the hash-table parameters (features), such as :test. > > Yeah, that's what I thought, too. That's something I can easily add. `map-into' would then look like the following `(defun map-into (map type &rest keywords))'. However, `keywords' would be ignored when converting to an alist. I'm not sure I like it. > Maybe Nicolas, maintainer of the library, wants to kick in (CC'ing > him). No you didn't :-P. Nico --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEKNO+2FH986tX/vk8IzWHpHwgeRAFAlnfbcYACgkQIzWHpHwg eRCL5QgAnz1A5ogY3+pTs99jgP2KQJUq8Tp+Pz1l777AoSnKpc7WApNquV77kZoq HULhbW0UfDQMfLAmLNBJvGxNNJmzQNG4eyBtRb3bS88wTJjprBEwnyi2WBqMDRw1 Xbuwql/vb8dfVaOScSvGqNGU3XxxIzp8laYk+408p+4i94pytFR3jlgyXkrWdL8I jxqdMHbEVm+lVxu4EFJmRr+Cr9RsS++US/t5GpMzsInN83QFVI8INq1nejlyeiXN Ga0EvibaPksHKcEuLdZ2Qd8vCr44NtIXb2ZhBkCwiaUbJ/O0bzblqM5NxusqlxM+ wG8+NENVnDYIIJXFtgPLKBp/4IAH9A== =ksU3 -----END PGP SIGNATURE----- --=-=-=-- From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Nicolas Petton Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Oct 2017 13:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams , Michael Heerdegen Cc: 28753@debbugs.gnu.org Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.150781501328791 (code B ref 28753); Thu, 12 Oct 2017 13:31:01 +0000 Received: (at 28753) by debbugs.gnu.org; 12 Oct 2017 13:30:13 +0000 Received: from localhost ([127.0.0.1]:35023 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2dYy-0007UI-P8 for submit@debbugs.gnu.org; Thu, 12 Oct 2017 09:30:12 -0400 Received: from petton.fr ([89.234.186.68]:59004) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2dYv-0007TD-1Z for 28753@debbugs.gnu.org; Thu, 12 Oct 2017 09:30:10 -0400 From: Nicolas Petton In-Reply-To: <3da0f75d-6000-410d-9e0b-ea293677b5ed@default> References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> <87r2uce9u8.fsf@web.de> <3da0f75d-6000-410d-9e0b-ea293677b5ed@default> Date: Thu, 12 Oct 2017 15:30:02 +0200 Message-ID: <87o9pcsdd1.fsf@petton.fr> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petton.fr; s=mail; t=1507815003; bh=fIbHeiFOi95vbnCYgM+hREZheFZcZKsCJJzJyPqpG7w=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:MIME-Version:Content-Type; b=cUtHw332+QO8VPXog8YxkJlI6ZwbimUJogURC92Zo9gS+iHh9wMQzXbWSaDjgJ9SQ8Aq1vd2CmRl2pSjE9uOrx1IXElGm21TljPc6zQbGfrV0DyOX6utzJmKh0zVVryMAI/YQZApLoz28r9nHSgnLdL+RZmc94RtMGj2gwSB8S8= X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) --=-=-= Content-Type: text/plain Drew Adams writes: > I imagine that `map-into' is intended to be extended to > more than alists and hash tables eventually. Yes, the same way `seq.el' can be extended (using generic functions). I haven't yet found the time to do it though, it's a pretty big refactoring of the library. Cheers, Nico --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEKNO+2FH986tX/vk8IzWHpHwgeRAFAlnfbloACgkQIzWHpHwg eRCAAQf/SzXBbgfZdGD8Gx5u2XCeLgEDtEqT540ZYHpPPlPT8L7P3TiBJf+Z1q2T wI2vc2QMOHHWzk9BNUhtspXhM8fVRC69WlCxN/UMaaZ4hQ2K/hOOFdcW2ATPGA9G Bzy81+MdWEqARg+ZTLPZnQuK0cWVen+ERtGd52sgEtsy/EGHyTyqxMpiUMwCtLA5 dBDlJZLp7dqB+PtWKz/mt1IIS/9w9dItMD7Ldr/+CYsMa/uelGfyUwJIhTmbKzSM Mzz/ulQMb/QlTyWCG4bC/OG/eVTA79WdmCsg7/BhU+DJiFFjX7kn6YMGUeotffoh Y5G2ZW6/yBXBnS+Cy7pWQkITxX5UpQ== =BT8p -----END PGP SIGNATURE----- --=-=-=-- From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Oct 2017 13:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Nicolas Petton Cc: 28753@debbugs.gnu.org, Drew Adams Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.150781603630539 (code B ref 28753); Thu, 12 Oct 2017 13:48:01 +0000 Received: (at 28753) by debbugs.gnu.org; 12 Oct 2017 13:47:16 +0000 Received: from localhost ([127.0.0.1]:35051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2dpS-0007wQ-8e for submit@debbugs.gnu.org; Thu, 12 Oct 2017 09:47:15 -0400 Received: from mout.web.de ([212.227.15.14]:51994) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2dpQ-0007wB-Dn for 28753@debbugs.gnu.org; Thu, 12 Oct 2017 09:47:12 -0400 Received: from drachen.dragon ([88.67.74.137]) by smtp.web.de (mrweb002 [213.165.67.108]) with ESMTPSA (Nemesis) id 0MT8x4-1ds5hP1Zag-00S4Ze; Thu, 12 Oct 2017 15:46:57 +0200 From: Michael Heerdegen References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> <87r2uce9u8.fsf@web.de> <3da0f75d-6000-410d-9e0b-ea293677b5ed@default> <87wp4038m0.fsf@web.de> <87r2u8sdh5.fsf@petton.fr> Date: Thu, 12 Oct 2017 15:46:56 +0200 In-Reply-To: <87r2u8sdh5.fsf@petton.fr> (Nicolas Petton's message of "Thu, 12 Oct 2017 15:27:34 +0200") Message-ID: <87k20032cv.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:/mwHwRCkJZspkZ9+jjY6kDCAA3FM4kWliXUWRuv5+rYSMzFF+1o KoN61Pkir3So2kiSyCwd0gWMsMy4MXeYKXqPOivFgfoOLukG4rgm75JJNLriLZzm1MPuMlW VZHUrJMxwiLRyVsCsSEYWH3IqF41JXr4ZZZCqrOPYuNVCXVF72qeiIGEfKe/tjtM7FwSOq6 2Z6ea7vwitJyRKedIL9eQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:R8UKvygxQDQ=:RbtHy8fxpelHNacuKXtL22 z+MITQ+AYwTZvDPQAQkrS3fLYpdYiaOZRhCALQk1dqWzaFw4JqEdHGgo/wRoFOdT72RRo6ywK IY5nOVVRaOl9rcgukQR+GvNyy3PNMgKvvxLpy0BFH2akKbEuSIxEQaOHm3PDMnp9/VmClwokD RUgRL4+ASwy3Dwra/YxaY8Zl47Ksmpo8TdV7hPDxTr5IQJUo0x90lfSwC3Kd9IGNEEDv+2Zo3 Fh6ZvJ5XLNAe0gcPGuG8RbQX7qBlxXTecW9q22wXChPIkIne1hJ0JRUt6xNy5W+GXhgYn2bMM UIH2yi6yRkypjFAzAFRU8fll/kZLN7Yce3uMa/lgQhanzNG3myLHmuvcpsNHvB2+uy8qBDBUc LgGHivAwl0ln01g0weaq4nfCsXUbF5eglGtpzDcxwiYUNv/OwbysMltKt9+Dhbv85JDy3ETdt 1Ax5gip17Hr/xwDSaLUhzSQG9nDFqesIpCWS4XyRZo4yuPzD+nzGSAgh75CxhaYkNVHlsSG/P PjA8E5gtJLjJzrIoiR6w+TuA9JN0fqI8xOH9MelAFM7Mfi22oHlmWGKw7YlmCEY9Vx2PtH/sw MUhuT/d/iD7s08kWxe2j1DmLFiTmQ+ozqbPuhK+BuCN4gmtQG3HKCd/rJpfqeHFlekp7P/qsZ WgBVRqreS2/0YBkERWLdkN1U+ts0oPyEn81jFMRJKvxc9mprhi6EGpPxaHNLJUGvnB6+mhlez cfTGMhxNLX99Z+FCfVd+JhRmJJ+uOAtyGaTb/mO7zuXgCsQ8wepeV6D7CxrRNjc8IrGatIPMS 4dAn62YHGRqVxzGApfFf636V35WsUpDzOhCsbvt28bE7YkOVEo= X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Nicolas Petton writes: > However, `keywords' would be ignored when converting to an alist. I'm > not sure I like it. If you don't like it, then maybe `map-into' is a misconception, and we should use different functions as Drew suggested instead. BTW, when I looked at map.el, i noticed that we have `map-some' and `map-every-p'. Is there a reason for the different naming style (one has -p, the other one has not)? Michael. From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Oct 2017 14:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Nicolas Petton , Michael Heerdegen Cc: 28753@debbugs.gnu.org Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.15078190264172 (code B ref 28753); Thu, 12 Oct 2017 14:38:01 +0000 Received: (at 28753) by debbugs.gnu.org; 12 Oct 2017 14:37:06 +0000 Received: from localhost ([127.0.0.1]:36207 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2ebi-00015E-4G for submit@debbugs.gnu.org; Thu, 12 Oct 2017 10:37:06 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:36517) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2ebg-00014h-KF for 28753@debbugs.gnu.org; Thu, 12 Oct 2017 10:37:05 -0400 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v9CEatJG032574 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 12 Oct 2017 14:36:55 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v9CEasId005412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 12 Oct 2017 14:36:55 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v9CEarqk003360; Thu, 12 Oct 2017 14:36:53 GMT MIME-Version: 1.0 Message-ID: <52a5f9a9-2fd9-49a6-9dd1-849f3c18b519@default> Date: Thu, 12 Oct 2017 07:36:52 -0700 (PDT) From: Drew Adams References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> <87r2uce9u8.fsf@web.de> <3da0f75d-6000-410d-9e0b-ea293677b5ed@default> <87wp4038m0.fsf@web.de> <87r2u8sdh5.fsf@petton.fr> In-Reply-To: <87r2u8sdh5.fsf@petton.fr> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4588.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0021.oracle.com [156.151.31.71] X-Spam-Score: -5.1 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.1 (-----) (Odd: I (and the bug-list?) don't seem to have received the reply from Michael that you quote below.) > Michael Heerdegen writes: > > > >> Actually, going from alist to hash table doesn't look so > >> useful with `map-into'. A caller should be able to specify > >> the hash-table parameters (features), such as :test. > > > > Yeah, that's what I thought, too. >=20 > That's something I can easily add. `map-into' would then look > like the following `(defun map-into (map type &rest keywords))'. &rest keywords does not treat the keywords as keywords. That's why we have (CL has) &keys. (And &rest can be used together with &keys.) > However, `keywords' would be ignored when converting to > an alist. I'm not sure I like it. Converting to an alist is different from converting to a hash table. As I mentioned, in particular a hash table has, as part of its definition, a :test function etc. An alist does not. Even an alist in CL does not, even though CL at least allows :test with `assoc'. So a general function that wants to handle the two the same way is out of luck. The best it can do is just allow whatever keyword args or other args a given target representation construction function might need. But in that case it cannot actually control such args in the call. See the code I sent originally. Note too the optional arg USE-LAST-P that I provided for conversion of an alist to a hash-table. Unlike a hash table, an alist is often used in a way that allows multiple entries for the same key, and in particular in a way where the first entry shadows the other entries for the same key. That means that, for that common alist use case, it is likely that the conversion to a hash table would use only the first alist entry with a given key, ignoring any others. But because an alist can be used in multiple ways, including ways where the other entries (shadowed in the typical case) are relevant, and because the most common case among those cases is for the last entry, not the first one, to be most relevant, we provide arg USE-LAST-P. When that arg is non-nil the last alist entry for a given key is used for the hash table. (If you get a hash table from an alist then you necessarily get only one entry for a given key. So you do not really capture the alist in all its functionality. Presumably someone asking for such a conversion knows this. We could, instead of providing an optional arg such as USE-LAST-P, just expect the user who wants the hash table to have already removed all alist entries with the same key except for the entry s?he wants. But that can be a bit of a bother, and it's easy to provide USE-LAST-P as a convenience.) It's great to have abstract, general-purpose functions that handle maps, sequences, streams, etc. But not all such things are handled the same way in Lisp code. An alist is itself quite general, so it can be and is used in different ways in different programs. There is no single, simple mapping from an arbitrary alist to a hash table, I think. We can provide a general-purpose function that chooses just one kind of mapping from an alist to, e.g., a hash table. But I'm guessing that we should also provide a function that gives you more control over the conversion mapping. IOW, maybe both a `map-into' kind of general-purpose behavior and a more specific `alist-to-hash-table' kind of behavior. (But for the time being, `map-into' is only for list <-> hash table, so for the time being it seems less useful than the more specific function.) From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Oct 2017 15:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Nicolas Petton Cc: Michael Heerdegen , 28753@debbugs.gnu.org, Drew Adams Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.150782377012004 (code B ref 28753); Thu, 12 Oct 2017 15:57:01 +0000 Received: (at 28753) by debbugs.gnu.org; 12 Oct 2017 15:56:10 +0000 Received: from localhost ([127.0.0.1]:36273 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2fqD-00037Y-Rq for submit@debbugs.gnu.org; Thu, 12 Oct 2017 11:56:10 -0400 Received: from mail-wm0-f43.google.com ([74.125.82.43]:55255) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2fqC-00037L-14 for 28753@debbugs.gnu.org; Thu, 12 Oct 2017 11:56:08 -0400 Received: by mail-wm0-f43.google.com with SMTP id i124so14619867wmf.3 for <28753@debbugs.gnu.org>; Thu, 12 Oct 2017 08:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ydHiv/CPAqcGp55WdHZreeAEq8KaR4qCsBBvRla92yk=; b=EEOHbBxXcOT/94l+TU0O201spykvZco9ZGxTz9+0yyIaDR2ERlYg1MnROKgugzni+2 dvES+c/PAoeUDphy7yxnWBd9dLdmRezj7vTqTXGRqZQLIMiw4nfSLGMrgyqUfkwKiT/1 SuFwoKlUExpCZc8bDkhDv3d3UWzSqlafA/IdX+gJOIweOhSk5hAizqoxSFD5Z5adHpv+ SA8axdxL7+SJ8sdpYettxxECw0kDTIImdmzscTXmsp9FbAFJULakvuRLz+fQ8+key++r lomdAuD1fpIg1T3gg3zZ+5lqR5abyy5jjaEwgvp2LiNLzcSQlmqOOjmfAlQ1EkhIHywM LHbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ydHiv/CPAqcGp55WdHZreeAEq8KaR4qCsBBvRla92yk=; b=UI0vIoH3vNF0da1XtqmgjUfcPqjwvAtiD79B8z3VmDBBUaI8OiHHS5V34LL/IiCGlT G30DOfpt28aCKYRagUVfBx5A6gcHSk64Ane5YxpkPkPUG64EcoUmSkH6LpChNUbNS6tP eTsIdez2SOPPX4yxM9S6nVi7lweKGA+LXHFry6MVbKf5DUkUo2ldAZnNGFm/uQ9mxHE9 LLYanlid5tNsV6NJONr5rIO6Pii4PY0Iprqhpd/ee+XW9BTJmPrU6opw/GvEjt6SzdwK 8VTRtXYn0go0kxcHKzpvKzFAZMw164XjsonC8h4NcX9KwLQAw/l8zqUFqxYhMqfFQ9Id wcbw== X-Gm-Message-State: AMCzsaVZQWg0a0TDBchXU+R9Km/x5CJ+kKsLxuopy1N6JrG2lMs+1cWc XUD5TxKe7PdGmi+e27Utar/NFBvgGZNCc8rHS70= X-Google-Smtp-Source: AOwi7QAqoDgcWKqQilcPQKO2/leAtzhbB4FcJDiAZUeevwpNI1+jTUvRX1kd4SPGuvGQRdO3WvhxmrYoDVpKb2jrxsU= X-Received: by 10.223.176.199 with SMTP id j7mr2766981wra.58.1507823762214; Thu, 12 Oct 2017 08:56:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.146.193 with HTTP; Thu, 12 Oct 2017 08:56:01 -0700 (PDT) In-Reply-To: <87r2u8sdh5.fsf@petton.fr> References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> <87r2uce9u8.fsf@web.de> <3da0f75d-6000-410d-9e0b-ea293677b5ed@default> <87wp4038m0.fsf@web.de> <87r2u8sdh5.fsf@petton.fr> From: Noam Postavsky Date: Thu, 12 Oct 2017 11:56:01 -0400 X-Google-Sender-Auth: 8AqEuN34h5oiMHhvdUZDi2IyWKM Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) On Thu, Oct 12, 2017 at 9:27 AM, Nicolas Petton wrote: > Michael Heerdegen writes: > >>> Actually, going from alist to hash table doesn't look so >>> useful with `map-into'. A caller should be able to specify >>> the hash-table parameters (features), such as :test. >> >> Yeah, that's what I thought, too. > > That's something I can easily add. `map-into' would then look like > the following `(defun map-into (map type &rest keywords))'. > > However, `keywords' would be ignored when converting to an alist. I'm > not sure I like it. What about just receiving the hash-table as a parameter: (defun map-into (map type) "Convert the map MAP into a map of type TYPE. TYPE can be one of the following symbols: `list', `hash-table'; or it can be a hash-table to use. MAP can be a list, hash-table or array." (pcase type (`list (map-pairs map)) (`hash-table (map--into-hash-table map)) ((pred hash-tablep) (map--into-existing-hash-table map type) (_ (error "Not a map type name: %S" type))))) (defun map--into-existing-hash-table (map hash-table) ...) From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Nov 2017 16:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Nicolas Petton , Michael Heerdegen Cc: 28753@debbugs.gnu.org Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.15099851719940 (code B ref 28753); Mon, 06 Nov 2017 16:20:01 +0000 Received: (at 28753) by debbugs.gnu.org; 6 Nov 2017 16:19:31 +0000 Received: from localhost ([127.0.0.1]:54427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBk7X-0002aG-4H for submit@debbugs.gnu.org; Mon, 06 Nov 2017 11:19:31 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:26812) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBk7U-0002Zy-9v for 28753@debbugs.gnu.org; Mon, 06 Nov 2017 11:19:29 -0500 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA6GJKBX000458 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 6 Nov 2017 16:19:21 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA6GJJQh005510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 6 Nov 2017 16:19:19 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vA6GJImw003135; Mon, 6 Nov 2017 16:19:18 GMT MIME-Version: 1.0 Message-ID: Date: Mon, 6 Nov 2017 08:19:16 -0800 (PST) From: Drew Adams References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> <87r2uce9u8.fsf@web.de> <3da0f75d-6000-410d-9e0b-ea293677b5ed@default> <87wp4038m0.fsf@web.de> <87r2u8sdh5.fsf@petton.fr> <52a5f9a9-2fd9-49a6-9dd1-849f3c18b519@default> In-Reply-To: <52a5f9a9-2fd9-49a6-9dd1-849f3c18b519@default> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4600.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-Spam-Score: -5.1 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.1 (-----) > It's great to have abstract, general-purpose > functions that handle maps, sequences, streams, > etc. But not all such things are handled the > same way in Lisp code. An alist is itself quite > general, so it can be and is used in different > ways in different programs. There is no single, > simple mapping from an arbitrary alist to a hash > table, I think. >=20 > We can provide a general-purpose function that > chooses just one kind of mapping from an alist > to, e.g., a hash table. But I'm guessing that we > should also provide a function that gives you more > control over the conversion mapping. IOW, maybe > both a `map-into' kind of general-purpose behavior > and a more specific `alist-to-hash-table' kind of > behavior. >=20 > (But for the time being, `map-into' is only for > list <-> hash table, so for the time being it > seems less useful than the more specific > function.) Any news on this? There is no general, abstract solution proposed, so far, to meet the needs met by the specific alist <-> hash-table code I sent. Should we not add that code or similar to Emacs? From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Nov 2017 00:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: Michael Heerdegen , Nicolas Petton , 28753@debbugs.gnu.org Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.151001561314181 (code B ref 28753); Tue, 07 Nov 2017 00:47:01 +0000 Received: (at 28753) by debbugs.gnu.org; 7 Nov 2017 00:46:53 +0000 Received: from localhost ([127.0.0.1]:54924 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBs2V-0003gd-UR for submit@debbugs.gnu.org; Mon, 06 Nov 2017 19:46:52 -0500 Received: from mail-io0-f174.google.com ([209.85.223.174]:45641) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBs2U-0003gO-CJ for 28753@debbugs.gnu.org; Mon, 06 Nov 2017 19:46:50 -0500 Received: by mail-io0-f174.google.com with SMTP id i38so374591iod.2 for <28753@debbugs.gnu.org>; Mon, 06 Nov 2017 16:46:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=7RJ9JGFpKyJFavZVS/z1eng5veOexXtHRWyXJVWRbwA=; b=Gjd6cJH+fwoPQQvGdSYwPydMBFArSkeF3cNoBYZRbSbXGL2f7r/sER0qp4UavGJHBw UkByiXwv8pD6a+ayJD1i0Kd3eVNjuIOTXcocFzrGizwTX2uiHcxX3UkrBrTaIkFYrPLB QwjXqW3vsdw/PxSD/hUTkxfAvQ4HF77+BrR6wcuokEpPvpdUb59neCC261f92KiKK4bK CpqwPyUO5SAj788sHQ50zo9Mm6GUNS+6QX3nVdoC0pBtPCrBVikuuA9t4pPH8dawMLkr WoKfl5i/+xztAbIMY2UYVfvWbIZPoE+mYCY9yzgdbYXU+pPb/VMGOtmie0vuBc7h3Ip+ SR/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=7RJ9JGFpKyJFavZVS/z1eng5veOexXtHRWyXJVWRbwA=; b=BX+MMn/UBd+IZSVvjocL56rR4zmjSGwVDbbSROJ4l6k8BnjTnLlK6OjSoRDBks1QgC rfffSE12hL2ZxfhXnqZHtuqwRGFrlQhlfjUe6eMCSWJJKFsU2P40JxKVGOQFydB24jMD 5+hDvbo64dxKmtsqdtBEodkAySW5GTofEoBgMv28gqY1qzDTZ2oqlLmGCMh+sDjpSBId 9ILqUzxz7tiUfhIIwA7jf8EsdWZuFy9t5E/D/H5TRhtsEJqf6nKaDDsFPbR20gjMSw0k 8Ew22tFL1ku+fFrhImKZde6xI3jM67R+CQnYhp5k6s8disXJSWdluogmbLzUptSYfSVU O0Mw== X-Gm-Message-State: AMCzsaUbgrZmvgBcpVXYQJ+YviEaMwzhRH4DKKlniHfrK4dOc/hMA6/y rsMobgXcMLOVpH21iN1mpUx+MA== X-Google-Smtp-Source: ABhQp+Soufo3ICg5T3sfUrFppFlQ3aKifg1kEFPn43CTnrkWT4FI4gplQsdZw73J4g9lZL2Ciijd8w== X-Received: by 10.107.201.144 with SMTP id z138mr20964140iof.223.1510015604494; Mon, 06 Nov 2017 16:46:44 -0800 (PST) Received: from zebian ([45.2.119.34]) by smtp.googlemail.com with ESMTPSA id x26sm140921ita.33.2017.11.06.16.46.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 06 Nov 2017 16:46:43 -0800 (PST) From: Noam Postavsky References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> <87r2uce9u8.fsf@web.de> <3da0f75d-6000-410d-9e0b-ea293677b5ed@default> <87wp4038m0.fsf@web.de> <87r2u8sdh5.fsf@petton.fr> <52a5f9a9-2fd9-49a6-9dd1-849f3c18b519@default> Date: Mon, 06 Nov 2017 19:46:41 -0500 In-Reply-To: (Drew Adams's message of "Mon, 6 Nov 2017 08:19:16 -0800 (PST)") Message-ID: <87wp326hla.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) Drew Adams writes: > Any news on this? There is no general, abstract > solution proposed, so far, to meet the needs met > by the specific alist <-> hash-table code I sent. Did you have any comments for my proposal in #29? https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28753#29 From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Nov 2017 02:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Noam Postavsky Cc: Michael Heerdegen , Nicolas Petton , 28753@debbugs.gnu.org Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.151002148330828 (code B ref 28753); Tue, 07 Nov 2017 02:25:02 +0000 Received: (at 28753) by debbugs.gnu.org; 7 Nov 2017 02:24:43 +0000 Received: from localhost ([127.0.0.1]:54987 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBtZD-00081A-4i for submit@debbugs.gnu.org; Mon, 06 Nov 2017 21:24:43 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:17755) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBtZA-00080v-Or for 28753@debbugs.gnu.org; Mon, 06 Nov 2017 21:24:41 -0500 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA72OXi9031407 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 7 Nov 2017 02:24:34 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vA72OWrw031253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 7 Nov 2017 02:24:33 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vA72OVt4025528; Tue, 7 Nov 2017 02:24:31 GMT MIME-Version: 1.0 Message-ID: Date: Mon, 6 Nov 2017 18:24:26 -0800 (PST) From: Drew Adams References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> <87r2uce9u8.fsf@web.de> <3da0f75d-6000-410d-9e0b-ea293677b5ed@default> <87wp4038m0.fsf@web.de> <87r2u8sdh5.fsf@petton.fr> <52a5f9a9-2fd9-49a6-9dd1-849f3c18b519@default> <87wp326hla.fsf@users.sourceforge.net> In-Reply-To: <87wp326hla.fsf@users.sourceforge.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4600.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Source-IP: userv0021.oracle.com [156.151.31.71] X-Spam-Score: -5.1 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.1 (-----) > > Any news on this? There is no general, abstract > > solution proposed, so far, to meet the needs met > > by the specific alist <-> hash-table code I sent. >=20 > Did you have any comments for my proposal in #29? >=20 > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__debbugs.gnu.org_cgi_bugreport.cgi-3Fbug-3D28753- > 2329&d=3DDwIBAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3DkI3P6= ljGv6CTH > IKju0jqInF6AOwMCYRDQUmqX22rJ98&m=3D2PshIV1HLbvhys07NQMj0gaYobwyLDaPs6zHJY= zxwD > Y&s=3D30GvxP6lcqjxDwNDmk0njIsHZRQE1V1VGEA4JNZLf60&e=3D I don't see a complete proposal there. Your solution is apparently to punt, telling users to first create the hash table they need and then call a function that injects the alist key+value entries into that existing table. I think that's less clear than the function I provided. And in particular it does not provide a USE-LAST possibility. Does it? Would you be adding an optional such arg to `map--into-existing-hash-table', to handle this? Would the default behavior of that function use only the first entry with a given key, as is typical for an alist? If you show how to achieve all of what this definition achieves, then I guess it would be OK - provided its doc makes it just as clear as is clear for this function how to get specific alist-to-hash-table mappings: (cl-defun alist-to-hash-table (alist &optional use-last-p &key (test 'eql) weakness (size 65) (rehash-size 1.5) (rehash-threshold 0.= 8)) "Create and return a hash table created from ALIST. By default, if the same alist key is used in more than one alist entry then only the first entry is used for the hash table. Non-nil USE-LAST-P means override this to use only the last entry for a given key. See `make-hash-table' for the keyword arguments you can use and their default values." (let ((ht (make-hash-table :test test :weakness weakness :size size :rehash-size rehash-size :rehash-threshold rehash-threshold)) key val) (dolist (key.val alist) (setq key (car key.val) val (cdr key.val)) (when (or use-last-p (not (gethash key ht))) (puthash key val ht))) ht)) Users shouldn't have to reinvent that by figuring out how they might achieve its possibilities using `map-into'. You would presumably start by defining `map--into-existing-hash-table'. (Why would that function be "internal", BTW?) From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Nov 2017 02:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: Michael Heerdegen , Nicolas Petton , 28753@debbugs.gnu.org Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.1510023126992 (code B ref 28753); Tue, 07 Nov 2017 02:53:01 +0000 Received: (at 28753) by debbugs.gnu.org; 7 Nov 2017 02:52:06 +0000 Received: from localhost ([127.0.0.1]:55008 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBtzh-0000Fw-WB for submit@debbugs.gnu.org; Mon, 06 Nov 2017 21:52:06 -0500 Received: from mail-it0-f44.google.com ([209.85.214.44]:44921) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBtzh-0000FS-2S for 28753@debbugs.gnu.org; Mon, 06 Nov 2017 21:52:05 -0500 Received: by mail-it0-f44.google.com with SMTP id n195so5362741itg.1 for <28753@debbugs.gnu.org>; Mon, 06 Nov 2017 18:52:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=75kKUZRSMsALINmWeFp3EJDbLKdsXXaoWTEdtt77d94=; b=fjjEdp2QMw/D3shp++rFsOkJlGF/dx8x7sbgLSlDb2/jjazH8uY1WKvENOWJLv/NVQ VTWymRG5zEmH8IwsUPkirAJBDdLu78tDBNyap1nl/EvqqF8Qxf/Li+A8KZOuxPUBUW2p BMRQBpNWcXZwFom2rooERp/L41tG6Z7vNfdHC/Mtt2pTvk6WWKJo2DxT77ypnxPdjH7T g3DvsvLpzIi3wxb+NhJy+9IPpbWlgijhSFsWe1zubAos7JNg/CMzR/5wtaYInKHP4iI9 Cd9gD62vUqUf5cVp64dbRxE037ixmLex8/KzISJwDqOrlQtkXO9apSeCAEBYtIBHo3zO ld7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=75kKUZRSMsALINmWeFp3EJDbLKdsXXaoWTEdtt77d94=; b=fvFUMMXQ1ZO89D9aEf+AmdlGzdGJEK3Yx8LRAEhQUgKCM+KaNoS46/t0oc/EeTRwri VjCcnSgcJCUtq+ihqtV1VoJ8V7usS0Dq9vOcNzWCeGoLpbl3oJXocu6xa995vd5UZEXf CFb1Qf7ZXPZ3/QWwM0n3QPaRhbj/dM9S5u65dqHWEU/417I8wMuBvqYrGd3n4h1oA7Y5 4EGsYIAm0plALwrROXFB2n4JDLFV1T+vl5j/vKA5ZSTcQSHZHX+HGh2vpCLSkxBQ2A7V 7TEMydJ9Tlu/KHA3yvY47I+ktQbwT3g636wjpiaeeb0PGTWJ4+W5Hhp+Fc/QKg0QDpWS XjeA== X-Gm-Message-State: AJaThX68yUXq8ozpeAwz3Le01zL8Im7eZSnD1W8k26d+ddo2Br63VR7Z 9GegcB/csClZWOhWoZ20/Sd4dg== X-Google-Smtp-Source: ABhQp+R55YXAom4kJUOa7PaxUzp6nrDYjiic4S2Yy1TRk+TRa0t9FuQI6qBQTEFkFeqAAdFziKZV5g== X-Received: by 10.36.66.80 with SMTP id i77mr406116itb.102.1510023119206; Mon, 06 Nov 2017 18:51:59 -0800 (PST) Received: from zebian ([45.2.119.34]) by smtp.googlemail.com with ESMTPSA id e68sm7014523ite.0.2017.11.06.18.51.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 06 Nov 2017 18:51:57 -0800 (PST) From: Noam Postavsky References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> <87r2uce9u8.fsf@web.de> <3da0f75d-6000-410d-9e0b-ea293677b5ed@default> <87wp4038m0.fsf@web.de> <87r2u8sdh5.fsf@petton.fr> <52a5f9a9-2fd9-49a6-9dd1-849f3c18b519@default> <87wp326hla.fsf@users.sourceforge.net> Date: Mon, 06 Nov 2017 21:51:56 -0500 In-Reply-To: (Drew Adams's message of "Mon, 6 Nov 2017 18:24:26 -0800 (PST)") Message-ID: <87inem6bsj.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) Drew Adams writes: >> Did you have any comments for my proposal in #29? > > I don't see a complete proposal there. Correct, I wanted to get comments on the whether the approach was acceptable before finishing it. > Your solution is apparently to punt, telling users to > first create the hash table they need and then call a > function that injects the alist key+value entries into > that existing table. Yes, if they want a hash table with specific parameters. > I think that's less clear than the function I provided. I think it has the advantage that the conversion function doesn't have to know about all the possible parameters involved in hash table creation. Therefore the interface is simpler. > And in particular it does not provide a USE-LAST > possibility. No, but I think it could be easily added. > You would presumably start by defining > `map--into-existing-hash-table'. (Why would that function > be "internal", BTW?) I meant it as a variant on `map--into-hash-table', so it uses the same naming convention. From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Nov 2017 13:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Noam Postavsky Cc: Nicolas Petton , 28753@debbugs.gnu.org, Drew Adams Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.15100613364778 (code B ref 28753); Tue, 07 Nov 2017 13:29:01 +0000 Received: (at 28753) by debbugs.gnu.org; 7 Nov 2017 13:28:56 +0000 Received: from localhost ([127.0.0.1]:55336 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eC3w0-0001F0-6P for submit@debbugs.gnu.org; Tue, 07 Nov 2017 08:28:56 -0500 Received: from mout.web.de ([212.227.15.4]:58756) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eC3vy-0001Eg-5L for 28753@debbugs.gnu.org; Tue, 07 Nov 2017 08:28:54 -0500 Received: from drachen.dragon ([94.217.120.125]) by smtp.web.de (mrweb004 [213.165.67.108]) with ESMTPSA (Nemesis) id 0LwU2B-1fJWF825fD-018NUk; Tue, 07 Nov 2017 14:28:29 +0100 From: Michael Heerdegen References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> <87r2uce9u8.fsf@web.de> <3da0f75d-6000-410d-9e0b-ea293677b5ed@default> <87wp4038m0.fsf@web.de> <87r2u8sdh5.fsf@petton.fr> <52a5f9a9-2fd9-49a6-9dd1-849f3c18b519@default> <87wp326hla.fsf@users.sourceforge.net> Date: Tue, 07 Nov 2017 14:28:28 +0100 In-Reply-To: <87wp326hla.fsf@users.sourceforge.net> (Noam Postavsky's message of "Mon, 06 Nov 2017 19:46:41 -0500") Message-ID: <87d14uusjn.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:RyKHIrhH3A1fAtCYsJZ6k/XZ8gSNnUoiwcUgYT/vTZ/F8OMWsBL q53WYoKwNtuDk9B45ZRbJ2y2fNOmwjTsu4mMqTadDz3EomXPxPfsyxqdC9EffuqidrjZ9hK JQBMURTLw7RCO90xU5QWmkMFnNi6gM1gnqVKHqqBpc5Po4bd3lR802mM1C1OIKyKjPRrbKP A/tjqhKuvSDDijpXvTu+Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:xomg6wWb9Iw=:G9nZMYlLeyLW2iEPb4ddud AiLKALR42w0YgBQOjtczEfSHNQiaxg25DYT0zzTts9WlqEEyL7O5ffERt3B7aPDOyyOph2Xde 4Vqn4p7/Wyy3nBCbLuq/E1OAmCE0EPpplFKgqW98S7CmvrdTT0+5A96eb3rLheA5ZFR5SOIQ8 zx3dZpA8Mm/XADAbHkieJ4R/PLUBzwTgSdk4zUTu+NRctWIum4aqhY1uNY2bYvMUJi97jWPXH 8KPitxPzcVX4DGXnaw9L7tfimGk3DJohfwYos87+quBmf05L1LJMK0Kg6ssekpvBFKrR4mgGk ylNlxqXkma09xNJuKAgzcTPR7M0wqqGGsk4J3MfnodeOohDCJTPblgcCHRx+wduHDFndubaC0 +bcEIXntQG2woUBdgFnnM9H21dW+Gyj3tun+b9JCVIaoNLL/zILcH1V3AcDZhu0mkjcY1ICcL 5Wt/uZ6OrGk2B0U7kC4UHxC6UwDczEvyVLAy0pZKbgvNYfDCENMYFCzxLjMTBY0FnB8gWncog mUinXksqp95H+4OhSGl9TzHwHqizwdW6BsD0VhMbHE9+71Q6ysvNxT19jY5J7Uh21H7ffr4c5 i0Lw2oLryKZxUU0txH/v/VUcTu3nsatWwHbaFxnp/KdEvGvUK1+pjcAik2R5shoRviziO9cDP ESvChqyUCcjH+ObTisKJc+YM+AYRzIU/XAh/n6GVd0OeFL49rp8kNQkKjX9kCC0l5NUgU/YGS NYMREmU3HDJgxjSVG1BSG43AItCQ8sn4RymY894RUi7auxp1IVlUf6tk6Vh3C4BJWXOLWhxZP rRVRab3jU+3xhUuABNL2ZSWyDRO+rvHFLsNa08IhIeBdVNU7EA= X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Noam Postavsky writes: > Drew Adams writes: > > > Any news on this? There is no general, abstract > > solution proposed, so far, to meet the needs met > > by the specific alist <-> hash-table code I sent. > > Did you have any comments for my proposal in #29? That's clever. OTOH I'm not convinced that `map-into' is a good abstraction. Every goal type might have an individual set of useful parameters, especially when we want to add support for other map types in the future. Our choice now to unite those in one conversion interface function might result in quite a mess later. Michael. From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Dec 2017 20:41:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Michael Heerdegen Cc: Nicolas Petton , 28753@debbugs.gnu.org, Noam Postavsky Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.151466644427989 (code B ref 28753); Sat, 30 Dec 2017 20:41:03 +0000 Received: (at 28753) by debbugs.gnu.org; 30 Dec 2017 20:40:44 +0000 Received: from localhost ([127.0.0.1]:58159 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eVNvv-0007HN-W0 for submit@debbugs.gnu.org; Sat, 30 Dec 2017 15:40:44 -0500 Received: from mail-qk0-f172.google.com ([209.85.220.172]:40568) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eVNvu-0007H4-2Q for 28753@debbugs.gnu.org; Sat, 30 Dec 2017 15:40:42 -0500 Received: by mail-qk0-f172.google.com with SMTP id q14so43359117qke.7 for <28753@debbugs.gnu.org>; Sat, 30 Dec 2017 12:40:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eVjUJGOFtkcswOFwdmjJYnyzzmFejNKU/+Ua5U3iIGY=; b=Y7ccO6qNbA57pPEuU/jzVyGOb+hQTYaerufRhHY0JcJd4LT170bLE/CzXsjMCsWVDG PjMNxZ8mtqasZ2dhpYVmHpR68A3nZr3Yv5bqZBj8qoMnRZfDGy7hF5dhjgj2nliZGBFC 2a6WQH4vm5jmY40wIbCCnX/TIHeN+M+gFqfwP8ppZtgT8RR/lFyeA6OCXEnp6CDCFcb0 +nbfkXweMjnmlLQofKdoaIYWp+V61wJLGLivt4okvmz18bMfFIFkikIQkli3Rhj3bWFf DAC0BQTFO3xWSIYOvtUsbHNiHi+04+VCK/YQaCFeY1LcrGm0mcd5nd9JZQkBMDCFgVht ahTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eVjUJGOFtkcswOFwdmjJYnyzzmFejNKU/+Ua5U3iIGY=; b=d3ROoD6T6n5kpbh38t3CqOqnpp2q0heXMwLsG3P5g2QiTiXfu9R66QXGdjaSbwZxk3 7BQGVUVUULi7utS73nppWgMGi1dMnnugnxJASD2WSQHSvruFR+gboydNlrbeMjcIuf29 bVZy4OQJjRWoKoluZF1uFa2POAJpPxStIwEEjtmGuVqUgpsblzaP7ZRTpHIpM3ia1lMw 3adHzl6gBgYcix6tUlGnziyJooOHPg4QPorIFc3etQM2Eph+E+IIPndLqDaxfeBOgYxX hQdU7YF2Xxyk4qsnooTIguGdZju5FFzIi/P7/PZApheUr9OvWOWJRSAQzmIdmgJjWJGi LC0A== X-Gm-Message-State: AKGB3mIjwN+QsY5SGgkNHSWPAGmBs+qjNIkMAUNdAslTOinQQoX24C2w QSekvW01sTseQYnPb20AQ3RUKdkBt95p15B+22I= X-Google-Smtp-Source: ACJfBotl2SyRUQ70WoEnlJ418dj/m93dCSXPenbd7qUdg4RT39QI2vLnmRxfwcvz3RGwd6ayUVhnvuMYmRnvJA/VU7M= X-Received: by 10.55.20.198 with SMTP id 67mr7050659qku.55.1514666436590; Sat, 30 Dec 2017 12:40:36 -0800 (PST) MIME-Version: 1.0 References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> <87r2uce9u8.fsf@web.de> <3da0f75d-6000-410d-9e0b-ea293677b5ed@default> <87wp4038m0.fsf@web.de> <87r2u8sdh5.fsf@petton.fr> <52a5f9a9-2fd9-49a6-9dd1-849f3c18b519@default> <87wp326hla.fsf@users.sourceforge.net> <87d14uusjn.fsf@web.de> In-Reply-To: <87d14uusjn.fsf@web.de> From: Philipp Stephani Date: Sat, 30 Dec 2017 20:40:25 +0000 Message-ID: Content-Type: multipart/alternative; boundary="001a11447f10e803a2056194c245" X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) --001a11447f10e803a2056194c245 Content-Type: text/plain; charset="UTF-8" Michael Heerdegen schrieb am Di., 7. Nov. 2017 um 14:29 Uhr: > Noam Postavsky writes: > > > Drew Adams writes: > > > > > Any news on this? There is no general, abstract > > > solution proposed, so far, to meet the needs met > > > by the specific alist <-> hash-table code I sent. > > > > Did you have any comments for my proposal in #29? > > That's clever. > > OTOH I'm not convinced that `map-into' is a good abstraction. Every > goal type might have an individual set of useful parameters, especially > when we want to add support for other map types in the future. Our > choice now to unite those in one conversion interface function might > result in quite a mess later. > I don't think a unified conversion interface is that important. The various structures used for mappings are just too different. For example, alists and plists aren't real types, they are only defined by their usage. Hash tables, on the other hand, are real types, with a per-object comparison function, a non-nil empty value, etc. These two kinds of objects are just too different to treat uniformly. Also, in most cases it is statically known which kinds of objects are involved, so a generic function that dynamically selects on the type of object isn't that useful. How about adding some simple conversion functions to subr.el such as (defun alist-to-hashtable (alist &rest keys) ...) (defun hashtable-to-alist (hashtable) ...) --001a11447f10e803a2056194c245 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Michae= l Heerdegen <michael_heerdeg= en@web.de> schrieb am Di., 7. Nov. 2017 um 14:29=C2=A0Uhr:
=
Noam Postavsky <npostavs@users.sourceforge.net> writes:

> Drew Adams <drew.adams@oracle.com> writes:
>
> > Any news on this?=C2=A0 There is no general, abstract
> > solution proposed, so far, to meet the needs met
> > by the specific alist <-> hash-table code I sent.
>
> Did you have any comments for my proposal in #29?

That's clever.

OTOH I'm not convinced that `map-into' is a good abstraction.=C2=A0= Every
goal type might have an individual set of useful parameters, especially
when we want to add support for other map types in the future.=C2=A0 Our choice now to unite those in one conversion interface function might
result in quite a mess later.

I don't think a unified conversion int= erface is that important. The various structures used for mappings are just= too different. For example, alists and plists aren't real types, they = are only defined by their usage. Hash tables, on the other hand, are real t= ypes, with a per-object comparison function, a non-nil empty value, etc. Th= ese two kinds of objects are just too different to treat uniformly. Also, i= n most cases it is statically known which kinds of objects are involved, so= a generic function that dynamically selects on the type of object isn'= t that useful. How about adding some simple conversion functions to subr.el= such as
(defun alist-to-hashtable (alist &rest keys) ...)=C2= =A0
(defun hashtable-to-alist (hashtable) ...)
--001a11447f10e803a2056194c245-- From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Dec 2017 21:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Stephani , Michael Heerdegen Cc: Nicolas Petton , 28753@debbugs.gnu.org, Noam Postavsky Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.151466810230981 (code B ref 28753); Sat, 30 Dec 2017 21:09:02 +0000 Received: (at 28753) by debbugs.gnu.org; 30 Dec 2017 21:08:22 +0000 Received: from localhost ([127.0.0.1]:58171 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eVOMg-00083c-Lv for submit@debbugs.gnu.org; Sat, 30 Dec 2017 16:08:22 -0500 Received: from aserp2130.oracle.com ([141.146.126.79]:46334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eVOMf-00083H-PH for 28753@debbugs.gnu.org; Sat, 30 Dec 2017 16:08:22 -0500 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.21/8.16.0.21) with SMTP id vBUL8Fa1146232; Sat, 30 Dec 2017 21:08:15 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=kpcttGZyB1nFeueGJJ9zX1a5RjQF1Wz7FredZJLCzIg=; b=c9g06moVnpbp3m/ucdJWTfXs5DjojPP2godTBunXviRWxj+psm11ufp7VY8viay41XCO ZxmIOg9PQA2uUq5kUJ46vbNBOZ5xoleCLkYE0w7BO4QDyi3N1kskd7bOJup/CE2/R1mH HvvY4QGq4IFvl/ClZ157idXOLAThJnMhhkZElorKJs9r/RG1pwh8cCXZxQhUk2dL0cOf +qXYwGsWxxWkFeKDcDkUNUbwU62LU9bX7dAlwu2aRukI+uhauJ3Kf+I2lNaCbS8SDwxu Hvm1LdI/KJNhgPVnFz/BxacCfVkaEO9U99CevH8xPXcnuz0CA6zOLQsxHsALXFPgvLrP dw== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2f60aqgyt7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 30 Dec 2017 21:08:15 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vBUL8Ebe011654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 30 Dec 2017 21:08:14 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vBUL8Dxg025401; Sat, 30 Dec 2017 21:08:13 GMT MIME-Version: 1.0 Message-ID: Date: Sat, 30 Dec 2017 13:08:08 -0800 (PST) From: Drew Adams References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> <87r2uce9u8.fsf@web.de> <3da0f75d-6000-410d-9e0b-ea293677b5ed@default> <87wp4038m0.fsf@web.de> <87r2u8sdh5.fsf@petton.fr> <52a5f9a9-2fd9-49a6-9dd1-849f3c18b519@default> <87wp326hla.fsf@users.sourceforge.net> <87d14uusjn.fsf@web.de> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4627.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8760 signatures=668650 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=747 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712300312 X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > I don't think a unified conversion interface is that important. > The various structures used for mappings are just too different. > For example, alists and plists aren't real types, they are only > defined by their usage. Hash tables, on the other hand, are real > types, with a per-object comparison function, a non-nil empty > value, etc. These two kinds of objects are just too different > to treat uniformly. Also, in most cases it is statically known > which kinds of objects are involved, so a generic function that > dynamically selects on the type of object isn't that useful. > > How about adding some simple conversion functions to subr.el such as >=20 > (defun alist-to-hashtable (alist &rest keys) ...)=C2=A0 > (defun hashtable-to-alist (hashtable) ...) Which brings us back to the very first msg of this thread - the bug report. Please see the code I proposed there. And note the differences from the signature you show for `alist-to-hashtable'. I think those differences are important and your signature is not satisfactory. From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Dec 2017 21:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: Michael Heerdegen , Nicolas Petton , 28753@debbugs.gnu.org, Noam Postavsky Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.151466855131765 (code B ref 28753); Sat, 30 Dec 2017 21:16:01 +0000 Received: (at 28753) by debbugs.gnu.org; 30 Dec 2017 21:15:51 +0000 Received: from localhost ([127.0.0.1]:58175 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eVOTv-0008GG-EY for submit@debbugs.gnu.org; Sat, 30 Dec 2017 16:15:51 -0500 Received: from mail-qk0-f180.google.com ([209.85.220.180]:45359) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eVOTu-0008G2-2z for 28753@debbugs.gnu.org; Sat, 30 Dec 2017 16:15:50 -0500 Received: by mail-qk0-f180.google.com with SMTP id o126so43703230qke.12 for <28753@debbugs.gnu.org>; Sat, 30 Dec 2017 13:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XzhEvRUDe75Lf8zWZcAX+ktphyfmJMiEag8S2p+bJK0=; b=E+T0h6m0TJ7tAGFt99T5DSIsOXDmrPWdaRpyiC5b47MMCni7UFZ4jlv5WG8KAYZdXn u5smZyt3L8re95iwwi/s0c69deYe97hXzu1fYZy1C77W4cWljhBpGRtobCDaqheXzbbD qwApZ5B3s+ONTi6IE6o5hhWDD9vtgYfPfLLsXbJyvTmKJ9mJik3YPRTwo1hnkdIffves tuyFrAFAxcYz2mE/qcw5C0K4VwgG08+TY/a42hkeD21HZ/3Z5F9Pw4LjAVwqqyZSDgxl 2k/9mK19akiHFnCU9HuM+GVBnTmJorvK4I1sFBw2TL/3/6SsFUvt2VlNWuBPRI5ZGaJD HKVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XzhEvRUDe75Lf8zWZcAX+ktphyfmJMiEag8S2p+bJK0=; b=ov260yXR7L0EV19cE7dXhHzzrI4ZvY6UbNZDiYX4uYldmijed3D994WRyragQRpWk0 hQgqdpOTIsRC03NTD5MEv4k20G6cQHRHmsv116Ee6ZezdYziuWocH1LbRnHH0LRwoKxG sfaiLQfVjAq+hg0IpcK1u+HeaEYUYJFcxiJKepGpS0M3iqmZ9C8TGSzTX1g8aNX94X3Z MsnU8zvSGticYO7kWxShsVfdMDLzU6ovOVECoGBxdDwjBEEHvOnEAAc9iJVGehEjZr6j PSXb9hlbDTLFS6hiXqWIyN/YYH9uRjl5zU75p8hUa0zSd+y2EtKbI1iD19mVo3kTzvsq J1Nw== X-Gm-Message-State: AKGB3mKob8P/8ehX0VC+/uX7MYg4GkV90Lj1hnXGYg9ENaASXwaeJ54r vsIjFyYXAMkQNLTMT7yxqatw0B8StE7HJ6jEKrA= X-Google-Smtp-Source: ACJfBot0X8q8QfA3ZVv6BpGktaHQcF0yv+sNe6VCWYm331Urn2+BvhDk5d9Uk6YNFHLNDRqgvmE17tOJPF2Y1xDUBY0= X-Received: by 10.55.31.96 with SMTP id f93mr52130705qkf.151.1514668544628; Sat, 30 Dec 2017 13:15:44 -0800 (PST) MIME-Version: 1.0 References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> <87r2uce9u8.fsf@web.de> <3da0f75d-6000-410d-9e0b-ea293677b5ed@default> <87wp4038m0.fsf@web.de> <87r2u8sdh5.fsf@petton.fr> <52a5f9a9-2fd9-49a6-9dd1-849f3c18b519@default> <87wp326hla.fsf@users.sourceforge.net> <87d14uusjn.fsf@web.de> In-Reply-To: From: Philipp Stephani Date: Sat, 30 Dec 2017 21:15:34 +0000 Message-ID: Content-Type: multipart/alternative; boundary="001a1147e32c8e21e8056195403f" X-Spam-Score: 0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --001a1147e32c8e21e8056195403f Content-Type: text/plain; charset="UTF-8" Drew Adams schrieb am Sa., 30. Dez. 2017 um 22:08 Uhr: > > I don't think a unified conversion interface is that important. > > The various structures used for mappings are just too different. > > For example, alists and plists aren't real types, they are only > > defined by their usage. Hash tables, on the other hand, are real > > types, with a per-object comparison function, a non-nil empty > > value, etc. These two kinds of objects are just too different > > to treat uniformly. Also, in most cases it is statically known > > which kinds of objects are involved, so a generic function that > > dynamically selects on the type of object isn't that useful. > > > > How about adding some simple conversion functions to subr.el such as > > > > (defun alist-to-hashtable (alist &rest keys) ...) > > (defun hashtable-to-alist (hashtable) ...) > > Which brings us back to the very first msg of this thread - > the bug report. Please see the code I proposed there. > OK thanks. I think your definitions would be a useful addition to subr.el. > > And note the differences from the signature you show for > `alist-to-hashtable'. I think those differences are > important and your signature is not satisfactory. > NB, I have the `&rest keys` in my arglist, with similar intentions as your definition. --001a1147e32c8e21e8056195403f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Drew A= dams <drew.adams@oracle.com= > schrieb am Sa., 30. Dez. 2017 um 22:08=C2=A0Uhr:
> I don't think a unified conversion interface is= that important.
> The various structures used for mappings are just too different.
> For example, alists and plists aren't real types, they are only > defined by their usage. Hash tables, on the other hand, are real
> types, with a per-object comparison function, a non-nil empty
> value, etc. These two kinds of objects are just too different
> to treat uniformly. Also, in most cases it is statically known
> which kinds of objects are involved, so a generic function that
> dynamically selects on the type of object isn't that useful.
>
> How about adding some simple conversion functions to subr.el such as >
> (defun alist-to-hashtable (alist &rest keys) ...)=C2=A0
> (defun hashtable-to-alist (hashtable) ...)

Which brings us back to the very first msg of this thread -
the bug report.=C2=A0 Please see the code I proposed there.

OK thanks. I think your definitions would be a useful = addition to subr.el.
=C2=A0

And note the differences from the signature you show for
`alist-to-hashtable'.=C2=A0 I think those differences are
important and your signature is not satisfactory.

=
NB, I have the `&rest keys` in my arglist, with similar inte= ntions as your definition.=C2=A0
--001a1147e32c8e21e8056195403f-- From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Dec 2017 21:28:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: 28753@debbugs.gnu.org Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.1514669224541 (code B ref 28753); Sat, 30 Dec 2017 21:28:03 +0000 Received: (at 28753) by debbugs.gnu.org; 30 Dec 2017 21:27:04 +0000 Received: from localhost ([127.0.0.1]:58184 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eVOem-00008f-Hc for submit@debbugs.gnu.org; Sat, 30 Dec 2017 16:27:04 -0500 Received: from mail-qt0-f179.google.com ([209.85.216.179]:40066) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eVOel-00008A-DY for 28753@debbugs.gnu.org; Sat, 30 Dec 2017 16:27:03 -0500 Received: by mail-qt0-f179.google.com with SMTP id u42so57494366qte.7 for <28753@debbugs.gnu.org>; Sat, 30 Dec 2017 13:27:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ke2WB5kQmS9U1SF2ToK5PLalj+Zs7UTFQhgcMVTW3LI=; b=TN2Be83tVSrJ4ROvYuMTeFqdfPgRhaY9qHdGITs6gZ8QhO44C1OHYC9yk53Mz99GDC nAI2AtyLW9sPA2RpiPqLL1unsIp3aSeWLXot6JbG+aonjruiKmDwG8EqygDg9cKFuo+R 49pxZcxvtbC6lLD0JeT9LZYQPDNdzXs6LxbSMyDifiNzwAAdi8E0YRDfoKSzc/5Fnxbf +RZtYVw8/tzjRh7P/I8PyM5XeDKorV0VdXZy8eywXP6T94INnYicNlmhckfFfLjskebN muyinXbSZII0d8hQbS+/Qn+kvUx3cAKzDGw0HtQzeYtZLiStj1K2ZA+LqlYT59qvns/G Zhdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ke2WB5kQmS9U1SF2ToK5PLalj+Zs7UTFQhgcMVTW3LI=; b=UZ3bG5fNvmTRd4PgJtZcjofgZMTe6H9U9T/+PGXd+2itpiBwgm9Dp4kPHHr1z8+jE4 f8FAXpIdwEHuX0xwzZ/+lAGX+akiY7DK3nmSvYpr/U2lPKxkLPc+wnwRbA84RlRQkBpQ uM2petbJHH+BOXoeBzlQ039WSbugpC7fA1RecK8k4MQ3KBy5JKr4GhUJb/ork7sccCWn rmR/NFo8734rVqH4B707TKd+IUXyyWsCYs1PdIxk4xKa8GnHoS27m5ty4kj/xTVG8FEy Xf2wmBSXbXZ8hiHbPNfWYEYiJyr9vTxiiaF64cTuIk1/BNylJoALTeWAyGw9uzz2Kl9+ Y2jw== X-Gm-Message-State: AKGB3mLwNVPVej3epMMelkZxBeFE24A/YBNHMCe/Ua2KQVgAmjPfJES0 TJlI02HQjQKzT5ltx262k4PbnFsujnZ2Gbn3YtE= X-Google-Smtp-Source: ACJfBougU4kw1i2nPf4whchphpwZr9pddURV6CqbHwZQi7tU3v09WGEU7pmkoJZLlnpbQ/5kORwuj9gSFyXctzJwSF0= X-Received: by 10.200.27.76 with SMTP id p12mr54411736qtk.310.1514669217925; Sat, 30 Dec 2017 13:26:57 -0800 (PST) MIME-Version: 1.0 References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> In-Reply-To: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> From: Philipp Stephani Date: Sat, 30 Dec 2017 21:26:47 +0000 Message-ID: Content-Type: multipart/alternative; boundary="94eb2c122b70afd132056195686d" X-Spam-Score: -0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) --94eb2c122b70afd132056195686d Content-Type: text/plain; charset="UTF-8" Drew Adams schrieb am Mo., 9. Okt. 2017 um 02:27 Uhr: > Dunno whether functions like these might be useful. I use something > similar. If you think they're useful, consider adding them. > I think both are useful. > > (cl-defun alist-to-hash-table (alist &optional use-last-p > &key (test 'eql) weakness (size 65) > (rehash-size 1.5) (rehash-threshold > 0.8)) > "Create and return a hash table created from ALIST. > By default, if the same alist key is used in more than one alist entry > then only the first entry is used for the hash table. Non-nil > USE-LAST-P means override this to use only the last entry for a given > key. > > See `make-hash-table' for the keyword arguments you can use and their > default values." > (let ((ht (make-hash-table :test test :weakness weakness :size size > :rehash-size rehash-size :rehash-threshold > rehash-threshold)) > key val) > (dolist (key.val alist) > (setq key (car key.val) > val (cdr key.val)) > (when (or use-last-p (not (gethash key ht))) > This doesn't work if the value is nil. You need to use an uninterned symbol or some other unique object, e.g. (eq (gethash key ht #1='#:void) #1#) > (puthash key val ht))) > ht)) > I'd personally make use-last-p another keyword argument, though. > > (defun hash-table-to-alist (hash-table) > "Create and return an alist created from HASH-TABLE. > The order of alist entries is the same as the order of hash-table > entries (which normally is the order in which the entries were added > to the table)." > (let ((al ())) > (maphash (lambda (key val) (push (cons key val) al)) hash-table) > (nreverse al))) > > Hmm, is the order guaranteed? I haven't found anything in the Emacs Lisp manual about this, so maybe just leave out the parenthetical remark or say that the order is unspecified? --94eb2c122b70afd132056195686d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Drew A= dams <drew.adams@oracle.com= > schrieb am Mo., 9. Okt. 2017 um 02:27=C2=A0Uhr:
Dunno whether functions like these might be useful.=C2=A0= I use something
similar.=C2=A0 If you think they're useful, consider adding them.

I think both are useful.
=C2=A0

(cl-defun alist-to-hash-table (alist &optional use-last-p
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&key (test &= #39;eql) weakness (size 65)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(rehash-size 1.5= ) (rehash-threshold 0.8))
=C2=A0 "Create and return a hash table created from ALIST.
By default, if the same alist key is used in more than one alist entry
then only the first entry is used for the hash table.=C2=A0 Non-nil
USE-LAST-P means override this to use only the last entry for a given
key.

See `make-hash-table' for the keyword arguments you can use and their default values."
=C2=A0 (let ((ht=C2=A0 (make-hash-table :test test :weakness weakness :size= size
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :rehash-size rehash-size :rehash-threshold = rehash-threshold))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 key val)
=C2=A0 =C2=A0 (dolist (key.val=C2=A0 alist)
=C2=A0 =C2=A0 =C2=A0 (setq key=C2=A0 (car key.val)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 val=C2=A0 (cdr key.val))
=C2=A0 =C2=A0 =C2=A0 (when (or use-last-p=C2=A0 (not (gethash key ht)))
=

This doesn't work if the value is nil.= You need to use an uninterned symbol or some other unique object, e.g.
(eq (gethash key ht #1=3D'#:void) #1#)
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (puthash key val ht)))
=C2=A0 =C2=A0 ht))

I'd personally m= ake use-last-p another keyword argument, though.
=C2=A0

(defun hash-table-to-alist (hash-table)
=C2=A0 "Create and return an alist created from HASH-TABLE.
The order of alist entries is the same as the order of hash-table
entries (which normally is the order in which the entries were added
to the table)."
=C2=A0 (let ((al=C2=A0 ()))
=C2=A0 =C2=A0 (maphash (lambda (key val) (push (cons key val) al)) hash-tab= le)
=C2=A0 =C2=A0 (nreverse al)))


Hmm, is the order guaranteed? I haven'= t found anything in the Emacs Lisp manual about this, so maybe just leave o= ut the parenthetical remark or say that the order is unspecified?=C2=A0
--94eb2c122b70afd132056195686d-- From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 Dec 2017 00:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Stephani Cc: 28753@debbugs.gnu.org Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.151467850023304 (code B ref 28753); Sun, 31 Dec 2017 00:02:01 +0000 Received: (at 28753) by debbugs.gnu.org; 31 Dec 2017 00:01:40 +0000 Received: from localhost ([127.0.0.1]:58240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eVR4N-00063Q-Q1 for submit@debbugs.gnu.org; Sat, 30 Dec 2017 19:01:40 -0500 Received: from userp2130.oracle.com ([156.151.31.86]:35672) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eVR4L-0005wt-QJ for 28753@debbugs.gnu.org; Sat, 30 Dec 2017 19:01:38 -0500 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.21/8.16.0.21) with SMTP id vBUNvYSp013540; Sun, 31 Dec 2017 00:01:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=sCjrNRsrDeXdcCU0xHWzynTdpYCWTo9znx6IknWgcKo=; b=uUspqpwxl6GwrUR7t53sDhSERe7305Zd2crL/Qm617yeqHRiNRsRuhP91O54jvp65ivQ T+rXzvALOxXWtHo2P6oV+Z+nxi6geFH0ORifTlQtVWv9xH1T8U5EuAUGQws/bxdqxVTK J6AlPN3dVOQzckCf2lgC0h5qmuY+8FZjDkptC7bhj2HOvskJAMTjcKSINXklxFXstrlx GkvJ6zWcoszGxDxNdDL4zxXdbdPUD5qU4AvUWh+9YmuEN17im5JtQ8WcgpBM4O37wLSF 9cra0acoAyLfrEGie/PM9DHcHkSMDfMryu3+KB6jMkLcxfO182W5uI4KD6fu+3ooJU9o CA== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2f628490nr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 31 Dec 2017 00:01:31 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vBV01UrG015948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 31 Dec 2017 00:01:31 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vBV01UmC032290; Sun, 31 Dec 2017 00:01:30 GMT X-Message-Flag: MIME-Version: 1.0 Message-ID: <94d02ad7-d069-4195-b84a-13229dfa3e9a@default> Date: Sat, 30 Dec 2017 16:01:24 -0800 (PST) From: Drew Adams References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4627.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8760 signatures=668650 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712300351 X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) > > (when (or use-last-p=C2=A0 (not (gethash key ht))) > > This doesn't work if the value is nil.=20 I guess you mean that it doesn't DTRT if the cdr of an alist entry is `nil' - e.g. (foo) aka (foo . nil). > You need to use an uninterned symbol or some other unique object, e.g. > (eq (gethash key ht #1=3D'#:void) #1#) OK. Dunno which is clearer or whether there is some performance difference, but I would probably just bind a var to a unique cons, e.g. (cons 1 1), outside the `dolist'. E.g.: (let ((ht (make-hash-table :test test :weakness weakness :size size :rehash-size rehash-size :rehash-threshold rehash-threshold)) (uniq-cons (cons 1 1)) key val) (dolist (key.val alist) (setq key (car key.val) val (cdr key.val)) (when (or use-last-p (not (eq (gethash key ht uniq-cons)))) (puthash key val ht))) ht)) (With your approach of using an uninterned symbol, wouldn't you want to do the same thing: bind a var to it outside the `dolist', or would that make no real difference?) =C2=A0 > I'd personally make use-last-p another keyword argument, though. I don't have a strong objection, but why? > > (defun hash-table-to-alist (hash-table) > >=C2=A0 "Create and return an alist created from HASH-TABLE. > > The order of alist entries is the same as the order of hash-table > > entries (which normally is the order in which the entries were added > > to the table)." > >=C2=A0 (let ((al=C2=A0 ())) > >=C2=A0 =C2=A0 (maphash (lambda (key val) (push (cons key val) al)) hash-= table) > >=C2=A0 =C2=A0 (nreverse al))) > > Hmm, is the order guaranteed? I haven't found anything in the > Emacs Lisp manual about this, so maybe just leave out the > parenthetical remark or say that the order is unspecified? Good question! But it's not just the parenthetical part. If we couldn't say anything about the traversal order of `maphash' then the whole sentence would need to go. FWIW, I think it's pretty important. Order is quite important for alists, generally. Is there some reason we should not be able to count on this `maphash' behavior? That's the behavior I saw, AFAICT, but I didn't test much. I don't know whether it is guaranteed, but this use case involving conversion to alist looks like a good argument for some guarantee wrt order. I see that in Common Lisp nothing is said about the traversal by `maphash' over the hash table. This is all that is said: "For each entry in hash-table, maphash calls function on two arguments: the key of the entry and the value of the entry; maphash then returns nil. If entries are added to or deleted from the hash table while a maphash is in progress, the results are unpredictable, with one exception: if the function calls remhash to remove the entry currently being processed by the function, or performs a setf of gethash on that entry to change the associated value, then those operations will have the intended effect." - https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node155.html (Emacs doc should also probably say at least something about what happens when entries are added/removed during a `maphash' application.) If Emacs decides not to guarantee the order seen now, which I think is the order I described in the doc string above, then we would need to remove that sentence. That would be too bad for users of function `hash-table-to-alist', but at least they would, at least so far (and AFAICT), get that behavior, which is likely to be expected by them even if it is not documented. Another possibility (?): Allow _optional_ creation of a hash table that does preserve such ordering (even if just by recording order of entry and making that available to `maphash'). E.g., add a keyword arg for `make-hash-table' that does just that. Even if it turned out that this consistently or occasionally detracted from performance, it could be a useful option. Conversion to an alist would be a case in point. From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Mar 2018 19:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: 28753@debbugs.gnu.org Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.152019105717089 (code B ref 28753); Sun, 04 Mar 2018 19:18:02 +0000 Received: (at 28753) by debbugs.gnu.org; 4 Mar 2018 19:17:37 +0000 Received: from localhost ([127.0.0.1]:44706 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1esZ8a-0004RZ-IM for submit@debbugs.gnu.org; Sun, 04 Mar 2018 14:17:36 -0500 Received: from mail-lf0-f53.google.com ([209.85.215.53]:45565) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1esZ8Y-0004RH-Ng for 28753@debbugs.gnu.org; Sun, 04 Mar 2018 14:17:35 -0500 Received: by mail-lf0-f53.google.com with SMTP id h127so19030206lfg.12 for <28753@debbugs.gnu.org>; Sun, 04 Mar 2018 11:17:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i8QHCl7KpbIGbbp6RI+AZsqMZuWmEVgJSOJm1RuBweg=; b=JzGiq8U400CYgmqgnwJPVw/caG6hwwoAR93VYoqNS6n2GOSOjHpQbzxyUrf8i6BJI2 BJx3oZClQ6JswO+qk3PSogkdYuMXRbTKyonJIfgKM0sBV5rWB2jCB3pLiHBJ7HD1Q2uN QiIPDzIdmQcLXYPbTcpOUZuzvJ12cJdYLSEENZvMRw5fOfMr1qAx6oAUIOcaiH5owSJO ugzlGgrt/1ldtrSUO8Mnhc5Lowno5Evt91lKiiL1NQ7cruVKlCHb04dwzROvMIRE4OyO Y25LrzmWmG9bqyl1XK1DMNlSnsZC7Mqigj2qIt6WqOIl/peeMeu8xybzMYr3O758QhtU Cbvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i8QHCl7KpbIGbbp6RI+AZsqMZuWmEVgJSOJm1RuBweg=; b=kquYjhEColmEGk7rGWSzqfTb8hMEPHAMrJlKm/nGf3ho6ZZB8Fc43bDD8CYGLUPX8K befzJw1OTY0YR1QSCuGxPOWPxuSIKT30IAPI5tzyeKUjgcofRbF258MdkWb29fu4ooNC BoDox71CoOH3ExHroizhMQQugVeYWZPUCz6SAyIPnqI0pr5kiPfG72zLN6+xTv6r1/z/ P5qJCzmgPzRh85JI79zVaQCZyqkMBbhEpGtbliwHZDlZKWAsItHX1YCQbys3LB6xY5xK g782h1443CEEoSb+/KJ05nIzqVxZJjcA5sf3NevcgNPQ1lqw72+AuYwTciLw54fnoPso ibvw== X-Gm-Message-State: AElRT7HJWXrm9n30+wHYAdB3dE0EnCyjFUGV/YgdfRloDdagYvDplJ6U q1TMqF6maClVUEj1MasNY5wf35WJ/qGUeROeYWg= X-Google-Smtp-Source: AG47ELuQV3EZYBs9k4G8FD1KY5+T93t1NDC29Rwba1QauK1DulG6KSK27amHjazxhj6e7Ly5NQ3nmaCy2S6FtzB+hYg= X-Received: by 10.46.83.67 with SMTP id t3mr7898720ljd.63.1520191048553; Sun, 04 Mar 2018 11:17:28 -0800 (PST) MIME-Version: 1.0 References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> <94d02ad7-d069-4195-b84a-13229dfa3e9a@default> In-Reply-To: <94d02ad7-d069-4195-b84a-13229dfa3e9a@default> From: Philipp Stephani Date: Sun, 04 Mar 2018 19:17:17 +0000 Message-ID: Content-Type: multipart/alternative; boundary="94eb2c1cf776709b8605669b0fbe" X-Spam-Score: 0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --94eb2c1cf776709b8605669b0fbe Content-Type: text/plain; charset="UTF-8" Drew Adams schrieb am So., 31. Dez. 2017 um 01:01 Uhr: > > > (when (or use-last-p (not (gethash key ht))) > > > > This doesn't work if the value is nil. > > I guess you mean that it doesn't DTRT if the cdr of an alist > entry is `nil' - e.g. (foo) aka (foo . nil). > Yes. > > > You need to use an uninterned symbol or some other unique object, e.g. > > (eq (gethash key ht #1='#:void) #1#) > > OK. Dunno which is clearer or whether there is some > performance difference, but I would probably just bind > a var to a unique cons, e.g. (cons 1 1), outside the > `dolist'. E.g.: > > (let ((ht (make-hash-table :test test :weakness weakness > :size size :rehash-size rehash-size > :rehash-threshold rehash-threshold)) > (uniq-cons (cons 1 1)) > key val) > (dolist (key.val alist) > (setq key (car key.val) > val (cdr key.val)) > (when (or use-last-p (not (eq (gethash key ht uniq-cons)))) > (puthash key val ht))) > ht)) > > (With your approach of using an uninterned symbol, wouldn't > you want to do the same thing: bind a var to it outside the > `dolist', or would that make no real difference?) > It's no real difference. I just proposed the shortest way that works. > > > I'd personally make use-last-p another keyword argument, though. > > I don't have a strong objection, but why? > Especially for booleans it's much clearer if the parameter name is repeated on the call site. > > > > (defun hash-table-to-alist (hash-table) > > > "Create and return an alist created from HASH-TABLE. > > > The order of alist entries is the same as the order of hash-table > > > entries (which normally is the order in which the entries were added > > > to the table)." > > > (let ((al ())) > > > (maphash (lambda (key val) (push (cons key val) al)) hash-table) > > > (nreverse al))) > > > > Hmm, is the order guaranteed? I haven't found anything in the > > Emacs Lisp manual about this, so maybe just leave out the > > parenthetical remark or say that the order is unspecified? > > Good question! But it's not just the parenthetical part. > If we couldn't say anything about the traversal order of > `maphash' then the whole sentence would need to go. > > FWIW, I think it's pretty important. Order is quite > important for alists, generally. > > Is there some reason we should not be able to count on > this `maphash' behavior? > Order in hashtables is not guaranteed. If anything relies on the order, it's buggy. > > That's the behavior I saw, AFAICT, but I didn't test much. > > I don't know whether it is guaranteed, but this use case > involving conversion to alist looks like a good argument for > some guarantee wrt order. > No. Ordering guarantees require additional complexity and overhead, and are almost never needed. > > I see that in Common Lisp nothing is said about the traversal > by `maphash' over the hash table. This is all that is said: > > "For each entry in hash-table, maphash calls function on two > arguments: the key of the entry and the value of the entry; > maphash then returns nil. If entries are added to or deleted > from the hash table while a maphash is in progress, the results > are unpredictable, with one exception: if the function calls > remhash to remove the entry currently being processed by the > function, or performs a setf of gethash on that entry to change > the associated value, then those operations will have the > intended effect." > > - https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node155.html > > (Emacs doc should also probably say at least something about > what happens when entries are added/removed during a `maphash' > application.) > Yes. > > If Emacs decides not to guarantee the order seen now, which I > think is the order I described in the doc string above, then we > would need to remove that sentence. That would be too bad for > users of function `hash-table-to-alist', but at least they > would, at least so far (and AFAICT), get that behavior, which > is likely to be expected by them even if it is not documented. > > Another possibility (?): Allow _optional_ creation of a hash > table that does preserve such ordering (even if just by > recording order of entry and making that available to `maphash'). > E.g., add a keyword arg for `make-hash-table' that does just that. > > Even if it turned out that this consistently or occasionally > detracted from performance, it could be a useful option. > Conversion to an alist would be a case in point. > I don't think it would be worth the additional complexity. Hash tables have been available for ages in most programming languages, and almost never does anybody ask for ordering guarantees. (For example, I have never seen somebody using LinkedHashMap in Java.) Even for alists, most of the time maintaining insertion order is an irrelevant detail, most users care only about get/put/remove. --94eb2c1cf776709b8605669b0fbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Drew A= dams <drew.adams@oracle.com= > schrieb am So., 31. Dez. 2017 um 01:01=C2=A0Uhr:
> > (when (or use-last-p=C2=A0 (not (gethash key h= t)))
>
> This doesn't work if the value is nil.

I guess you mean that it doesn't DTRT if the cdr of an alist
entry is `nil' - e.g. (foo) aka (foo . nil).

<= /div>
Yes.
=C2=A0

> You need to use an uninterned symbol or some other unique object, e.g.=
> (eq (gethash key ht #1=3D'#:void) #1#)

OK.=C2=A0 Dunno which is clearer or whether there is some
performance difference, but I would probably just bind
a var to a unique cons, e.g. (cons 1 1), outside the
`dolist'.=C2=A0 E.g.:

(let ((ht (make-hash-table :test test :weakness weakness
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0:size size :rehash-size rehash-size
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0:rehash-threshold rehash-threshold))
=C2=A0 =C2=A0 =C2=A0 (uniq-cons (cons 1 1))
=C2=A0 =C2=A0 =C2=A0 key val)
=C2=A0 (dolist (key.val=C2=A0 alist)
=C2=A0 =C2=A0 (setq key=C2=A0 (car key.val)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 val=C2=A0 (cdr key.val))
=C2=A0 =C2=A0 (when (or use-last-p=C2=A0 (not (eq (gethash key ht uniq-cons= ))))
=C2=A0 =C2=A0 =C2=A0 (puthash key val ht)))
=C2=A0 ht))

(With your approach of using an uninterned symbol, wouldn't
you want to do the same thing: bind a var to it outside the
`dolist', or would that make no real difference?)
=
It's no real difference. I just proposed the shortest wa= y that works.
=C2=A0
=C2=A0
> I'd personally make use-last-p another keyword argument, though.
I don't have a strong objection, but why?

Especially for booleans it's much clearer if the parameter name = is repeated on the call site.
=C2=A0

> > (defun hash-table-to-alist (hash-table)
> >=C2=A0 "Create and return an alist created from HASH-TABLE. > > The order of alist entries is the same as the order of hash-table=
> > entries (which normally is the order in which the entries were ad= ded
> > to the table)."
> >=C2=A0 (let ((al=C2=A0 ()))
> >=C2=A0 =C2=A0 (maphash (lambda (key val) (push (cons key val) al))= hash-table)
> >=C2=A0 =C2=A0 (nreverse al)))
>
> Hmm, is the order guaranteed? I haven't found anything in the
> Emacs Lisp manual about this, so maybe just leave out the
> parenthetical remark or say that the order is unspecified?

Good question!=C2=A0 But it's not just the parenthetical part.
If we couldn't say anything about the traversal order of
`maphash' then the whole sentence would need to go.

FWIW, I think it's pretty important.=C2=A0 Order is quite
important for alists, generally.

Is there some reason we should not be able to count on
this `maphash' behavior?

Order in h= ashtables is not guaranteed. If anything relies on the order, it's bugg= y.
=C2=A0

That's the behavior I saw, AFAICT, but I didn't test much.

I don't know whether it is guaranteed, but this use case
involving conversion to alist looks like a good argument for
some guarantee wrt order.

No. Ordering = guarantees require additional complexity and overhead, and are almost never= needed.
=C2=A0

I see that in Common Lisp nothing is said about the traversal
by `maphash' over the hash table.=C2=A0 This is all that is said:

=C2=A0"For each entry in hash-table, maphash calls function on two
=C2=A0 arguments: the key of the entry and the value of the entry;
=C2=A0 maphash then returns nil. If entries are added to or deleted
=C2=A0 from the hash table while a maphash is in progress, the results
=C2=A0 are unpredictable, with one exception: if the function calls
=C2=A0 remhash to remove the entry currently being processed by the
=C2=A0 function, or performs a setf of gethash on that entry to change
=C2=A0 the associated value, then those operations will have the
=C2=A0 intended effect."

=C2=A0 - https://www.cs.cmu.edu/Groups/AI= /html/cltl/clm/node155.html

(Emacs doc should also probably say at least something about
what happens when entries are added/removed during a `maphash'
application.)

Yes.
=C2=A0

If Emacs decides not to guarantee the order seen now, which I
think is the order I described in the doc string above, then we
would need to remove that sentence.=C2=A0 That would be too bad for
users of function `hash-table-to-alist', but at least they
would, at least so far (and AFAICT), get that behavior, which
is likely to be expected by them even if it is not documented.

Another possibility (?): Allow _optional_ creation of a hash
table that does preserve such ordering (even if just by
recording order of entry and making that available to `maphash').
E.g., add a keyword arg for `make-hash-table' that does just that.

Even if it turned out that this consistently or occasionally
detracted from performance, it could be a useful option.
Conversion to an alist would be a case in point.

<= /div>
I don't think it would be worth the additional complexity. Ha= sh tables have been available for ages in most programming languages, and a= lmost never does anybody ask for ordering guarantees. (For example, I have = never seen somebody using LinkedHashMap in Java.)
Even for alists= , most of the time maintaining insertion order is an irrelevant detail, mos= t users care only about get/put/remove.=C2=A0
--94eb2c1cf776709b8605669b0fbe-- From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 05 Mar 2018 00:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Stephani Cc: 28753@debbugs.gnu.org Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.152020812510643 (code B ref 28753); Mon, 05 Mar 2018 00:03:02 +0000 Received: (at 28753) by debbugs.gnu.org; 5 Mar 2018 00:02:05 +0000 Received: from localhost ([127.0.0.1]:44857 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1esdZs-0002lb-Ki for submit@debbugs.gnu.org; Sun, 04 Mar 2018 19:02:04 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:53662) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1esdZq-0002l6-8h for 28753@debbugs.gnu.org; Sun, 04 Mar 2018 19:02:03 -0500 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2501u6R030845; Mon, 5 Mar 2018 00:01:56 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=8RopupvkpPAQS93SX3UIWYzXUhJum7199MDcJVA/VE0=; b=vB+p87Cp8O/7xYODyRTwP/9uPRj9lPGcrwZ6I0W4dxaV95k/B1f4DMmorfZe3qD3Pa+Y o1H1pvOUuyopt+jfTFQts809Xg4LSDlt5b4w/Ehc7+WGJTIX23euzQaWwFhCPbt9J8k5 +1pG4y3BTbOjfdG7/slxDODMRd53iOJcgNtlhBiLzELaj8C3uo7zrK9rFDcMK3gSHYrh ihnHBfhwhmvKYyKBg/BgDV8TmbYOwS0/pIo6jimVxd0/bD2tSSy1B9B3EIV37w1Akt1Z NhzLd/ry6EWW7+YDxOZAb7r6z9ijPdBaxYzf1OEsjdkNSDkL5rWMoEP9SC3e1D6+Yspg vw== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2ggtaa01u9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 05 Mar 2018 00:01:56 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w2501tVb014774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 5 Mar 2018 00:01:55 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w2501sY9008172; Mon, 5 Mar 2018 00:01:55 GMT MIME-Version: 1.0 Message-ID: <96840423-b3ba-4c4b-96d5-59a26d3e2455@default> Date: Sun, 4 Mar 2018 16:01:53 -0800 (PST) From: Drew Adams References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> <94d02ad7-d069-4195-b84a-13229dfa3e9a@default> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4654.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8822 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803040312 X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) >> Order is quite important for alists, generally. >> Is there some reason we should not be able to count on >> this `maphash' behavior? > > Order in hashtables is not guaranteed. If anything relies > on the order, it's buggy. =C2=A0 Emacs hash tables don't fall from the sky. They are not shadows of some Platonic ideal. This is a design choice. Emacs Lisp can implement hash tables any way it wants. >> I don't know whether it is guaranteed, but this use case >> involving conversion to alist looks like a good argument >> for some guarantee wrt order. > > No. Ordering guarantees require additional complexity and > overhead, and are almost never needed. Neither of those assertions has been demonstrated. Feel free to do so (how much overhead, how infrequent). And infrequency of use is not, alone, a good reason not to support something. Infrequent does not mean unimportant. >> Another possibility (?): Allow _optional_ creation of >> a hash table that does preserve such ordering (even if >> just by recording order of entry and making that >> available to `maphash'). E.g., add a keyword arg for >> `make-hash-table' that does just that. >> >> Even if it turned out that this consistently or occasionally >> detracted from performance, it could be a useful option. >> Conversion to an alist would be a case in point. > > I don't think it would be worth the additional complexity. Why? How much additional complexity? > Hash tables have been available for ages in most programming > languages, and almost never does anybody ask for ordering > guarantees. (For example, I have never seen somebody using > LinkedHashMap in Java.) Emacs Lisp has lots of features that are not in "most programming languages". Propertized strings, for one trivial example. > Even for alists, most of the time maintaining insertion > order is an irrelevant detail, What time maintaining insertion order? I can't imagine what you mean by that. > most users care only about get/put/remove. Not demonstrated. But even if it were true, it wouldn't follow that Lisp alist order is unimportant. Next you'll be suggesting that because lists are mutated relatively infrequently it is unimportant to be able to modify list structure or test cons equality with `eq'. Or that because true lists are used most of the time we might as well drop support of dotted lists. ---- Naive google search - https://www.javaspecialists.eu/archive/Issue073.html https://stackoverflow.com/questions/12998568/hashmap-vs-linkedhashmap-perfo= rmance-in-iteration-over-values/12998878 https://stackoverflow.com/questions/26623129/when-to-use-linkedhashmap-over= -hashmap-in-java From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Apr 2022 13:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Michael Heerdegen Cc: 28753@debbugs.gnu.org, Drew Adams Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.16506335507497 (code B ref 28753); Fri, 22 Apr 2022 13:20:02 +0000 Received: (at 28753) by debbugs.gnu.org; 22 Apr 2022 13:19:10 +0000 Received: from localhost ([127.0.0.1]:51998 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhtBm-0001wr-75 for submit@debbugs.gnu.org; Fri, 22 Apr 2022 09:19:10 -0400 Received: from quimby.gnus.org ([95.216.78.240]:38622) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhtBl-0001wa-8e for 28753@debbugs.gnu.org; Fri, 22 Apr 2022 09:19:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=NN6WnmCX64Gpi3B6SkEhNesaBUXpQ6/SQ8VY86fjKjs=; b=a5vc/ef6Xmd9WkfZCyJYsmyHWB fgIU4TbTOWJfIYooMa/ot/eEoieGq+Nr8cdSsaRKw3v3AJlb4Jq1kksXShDlwdm/TsfzhEHqt081Y y6H2jn95xCxoockn+A7iTWaRvhGYi+yLYgAlE9tDeGcvGCcOQmn92UDLmpPZ0QeUReEk=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nhtBb-0006oT-7r; Fri, 22 Apr 2022 15:19:01 +0200 From: Lars Ingebrigtsen References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> <87r2uce9u8.fsf@web.de> X-Now-Playing: ELpH's _Protection_: "Untitled" Date: Fri, 22 Apr 2022 15:18:58 +0200 In-Reply-To: <87r2uce9u8.fsf@web.de> (Michael Heerdegen's message of "Mon, 09 Oct 2017 15:20:47 +0200") Message-ID: <87sfq5xnlp.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Michael Heerdegen writes: > I think something very similar is provided by map.el: `map-into'. The discussion then went onto how to specify parameters to make-hash-table, and I see that this is fixed now like this: Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Michael Heerdegen writes: > I think something very similar is provided by map.el: `map-into'. The discussion then went onto how to specify parameters to make-hash-table, and I see that this is fixed now like this: (map-into '((1 . 3)) '(hash-table :test eql)) So there doesn't seem to be anything further to do here, and I'm therefore closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 22 09:19:15 2022 Received: (at control) by debbugs.gnu.org; 22 Apr 2022 13:19:16 +0000 Received: from localhost ([127.0.0.1]:52001 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhtBr-0001xA-DR for submit@debbugs.gnu.org; Fri, 22 Apr 2022 09:19:15 -0400 Received: from quimby.gnus.org ([95.216.78.240]:38638) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhtBo-0001wg-Tv for control@debbugs.gnu.org; Fri, 22 Apr 2022 09:19:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=HXfZgZQrnttd5M+CPlPFpxfW+J8lZ6BCLXhE5XnPrIc=; b=iTlsvXZrzXgE/CrIbSqmoT7TGi hNXUbfuDIu8G+JePUmw1Vff4Zrhp4REfa/JJQ2r9L0krkqqFtTa2L3TkKssdVv+asZ8DWdfUhY73l JS65t6je51p+5qc9IzaVwjWLvufHhWY6HTtqmJcl+/vT4ob7bqPwj4kTNBVGPYMu5gZk=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nhtBh-0006od-Bj for control@debbugs.gnu.org; Fri, 22 Apr 2022 15:19:07 +0200 Date: Fri, 22 Apr 2022 15:19:04 +0200 Message-Id: <87r15pxnlj.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #28753 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 28753 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 28753 quit From unknown Sat Jun 21 12:23:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Apr 2022 15:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28753 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen , Michael Heerdegen Cc: "28753@debbugs.gnu.org" <28753@debbugs.gnu.org> Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.165064091716072 (code B ref 28753); Fri, 22 Apr 2022 15:22:02 +0000 Received: (at 28753) by debbugs.gnu.org; 22 Apr 2022 15:21:57 +0000 Received: from localhost ([127.0.0.1]:54531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhv6b-0004BA-HM for submit@debbugs.gnu.org; Fri, 22 Apr 2022 11:21:57 -0400 Received: from mx0b-00069f02.pphosted.com ([205.220.177.32]:6608) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhv6W-0004Ax-T6 for 28753@debbugs.gnu.org; Fri, 22 Apr 2022 11:21:56 -0400 Received: from pps.filterd (m0246630.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 23MCwe99019340; Fri, 22 Apr 2022 15:21:52 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2021-07-09; bh=xP2U97qZ4robIKDI8aA2LaTTr7mgWaNbJSrQuJxnlpc=; b=jaCHXnfFPVArw25PvAulDDsTCD6E16MS50gW2gIC7MfTyA2i8fCkwZpLkji3uU4VaZHY l28ADMsieI/As3YSz/kYhTLZ25xDO4qojJVXeOKYoXXF2bzLw3D9q4MqMdpDTjIQ+YXC 1y4klxTM6lJxCmrCxppiH9b/ZkrZL8jlBOjlaXne5dZia9/GRV7+Cde3EUbqEeLa4teW tFhFDZrA9/WAbwF3/eYufAaobOw3sQkbhhpnIQ7dsWGU9LBu6a7vSmRX4iba4YPqo9BV AfCswDPmeYFVN52FO8PhYDdPmpBDLXr6j6sCDkyLyDfSLFykM5jYctWMqFCYQj/OZMfa eA== Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.appoci.oracle.com [138.1.37.129]) by mx0b-00069f02.pphosted.com with ESMTP id 3ffm7cxn25-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Apr 2022 15:21:51 +0000 Received: from pps.filterd (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (8.16.1.2/8.16.1.2) with SMTP id 23MFFvdK033850; Fri, 22 Apr 2022 15:21:50 GMT Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1anam02lp2049.outbound.protection.outlook.com [104.47.57.49]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com with ESMTP id 3ffm8dr1ch-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Apr 2022 15:21:50 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AmZ0EJWPxIKBGW08mbOxrzGzTubQXJ2X+XKUKcSROyfzyMiHxhzivJnohjLoTOF5uBTfKY99sGdBfUFrbR7fPJhJp7D2oR+QXSEXU7yUpELt0KMgl0aRIUigDI5rZZ2iO449V0hUkW5w9cjYXozdhR+RT0lUDXka6tw/Y0iEu/sJ8g5SH8N11AGR54U/qgjSds6SOHDkGt3vcbfelEKUMF9uAvUQcqFkMulQBrJylTuNvVGmbQksdn03tL7Vsc7XFgNhn6OCMj3XooPoD5uQuyTOqR1/bqj9ykGONVUV63M4K4qRuV2w73jrXt0PUFisGhVpOwt3JRXhZq6MKlZfzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xP2U97qZ4robIKDI8aA2LaTTr7mgWaNbJSrQuJxnlpc=; b=cqDQpp0bJZm9Hsi/tCyc/Fz/Px1ICtKFb2sRu8d5frDXUCgWsSeG7G5QWMGtoCVL6uSwsz0OpK/rNJgAW23Eu743ofb3zLrA9bSKIXYFbdl0xrHM2Epq0nfOCs9ZTQVU0XTxSu7/6kFjoOR6Xwjf2QelVmSVOlb68SF8SJP4oYu4n1d1TwubMEqseQD7ymIx06CeuGE8LYQxVP08vp9eeF8bs/WQrin66k+aQLQQsIQvCpISpYC1re+iLJwKWfHmfV8dk9HspqeaiQ7HGM6qkbDp2bIAP6FlE+vyaANc1PFnA6wmdMwjk0ITe7KoqB9bAO9NVwffZFk5HWM5aat3MQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xP2U97qZ4robIKDI8aA2LaTTr7mgWaNbJSrQuJxnlpc=; b=sbK63A3FSD+zsrisFSonHgjkOuFHkZNYC22pUbMI4CFRtn/fnOTb30rruYYvnHN+4h6SKl5916P8QeG520ULVwgI98YotlWgiQ1bH8qPYRvUJ7JWFj5Hnk1cBEbkg1rIog+JAFFugtomVTo3Bj2HIzTxrrnneeAKX/xASk1J4hk= Received: from SJ0PR10MB5488.namprd10.prod.outlook.com (2603:10b6:a03:37e::19) by CY4PR10MB1350.namprd10.prod.outlook.com (2603:10b6:903:25::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5186.13; Fri, 22 Apr 2022 15:21:48 +0000 Received: from SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::a0e7:5f38:ab50:5123]) by SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::a0e7:5f38:ab50:5123%9]) with mapi id 15.20.5186.015; Fri, 22 Apr 2022 15:21:48 +0000 From: Drew Adams Thread-Topic: [External] : Re: bug#28753: 25.3; Functions to get alist from hash table and vice versa Thread-Index: AQHYVkuOwuIlap93P0qlDGv4sPs6Xaz8C2NQ Date: Fri, 22 Apr 2022 15:21:48 +0000 Message-ID: References: <54ecd1bb-0c84-4b0a-b19e-3a89cbe832bc@default> <87r2uce9u8.fsf@web.de> <87sfq5xnlp.fsf@gnus.org> In-Reply-To: <87sfq5xnlp.fsf@gnus.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8018397e-b4af-4f6f-06fd-08da2473d1e9 x-ms-traffictypediagnostic: CY4PR10MB1350:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vTQdk3NyNQfyzOjuxTZenPWf/XJrlLy+kQXdC3OsuymnnBRXTFZG1VqSc22V8gbgqStUnqy5CXzGsjleaqWe8cLR9a+4rQ+Xxlja6LVhnD9y1sZgctKtSUUsrqWedpXbn8FUGv8Te6C/DwmQjxh8wcgSj+JME96T0wC08ABbI0fpMf95SvxeKZ34gfZifG9cW4Y98SK3nJDLAqH+y/8H8tClKUJPz4pNHTINWrqf+m1sjvRJ2s2QgMc9nLWAyFHW4OZkmCEIji8TVSalou/4sx42rHCBiea1AvFsH7M2A6svbcjNVaJQQwukbmALall+qFNCaexq5zyd/Iqg4MCgrfCOhuAM8xBJn8vFKky8xm4Ph1mp9eKHZzmO3+T4gWxFFF6ktEOaA0eevDGfX0LIh4j/XI7DpNIBUFXl+K62gGoRf0In5y8oVpJ9vjPeIaLFNrRo1hNr91k0a0Rp9nWPe/O1GHvl5OumwBTVHnh++hM6vIWtiLpJtx/t5x0gcwopEleugdWL4bp09m0Fpm+WKqOAGU1Ply8QTAAMq5IR5Mi3xZ5P1kzn0F/LioSN3qdegeuyPBhj97Py9SxgHjPwTdEP2tTfiSzy4Zx5YaRYzK8Re8w37dlsRjsQA7RXIl2xVJjhI9bJA/WkMM7Pr/3aqbEkFBzIjPWiCXV8V3o8QACbNrStM/N+OKTPDsKDo+SiMwrLFCQkzjG3zJggIceFww== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR10MB5488.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(508600001)(33656002)(5660300002)(186003)(8676002)(55016003)(8936002)(66946007)(66556008)(66476007)(66446008)(64756008)(76116006)(110136005)(316002)(71200400001)(38100700002)(38070700005)(44832011)(4326008)(4744005)(26005)(9686003)(86362001)(122000001)(52536014)(6506007)(7696005)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: Zd1Ib1u8HVlj84xhgcUqni+2aYW8kmGr5kni673qfbc4MVA5x7aSCsqk3iWYds0a+H4SmkUGh9qFH3GTM71DfYk9fthYsUDLGCpfFTr1ZsS5Sjt8Cbi4Y9RTDM6BEWPfH49Vl/esHPpoaw0ZCV4RPIF95wcXzQ7xNBcgH3W6xYFvHC11O5gVnfYDniqROsXsUvO7vWU9wUUoLOfducTC3MZHgewZxxeCPKAI24DKUQyAUn4srNQC6YGPwYrwSDk5p7/0jMBmW/8uRcei2A32QX3AImor/bOURzTyYBWGDsaHwzgvvft7PQMSXYtOhvDNdUozBox5O7OeaqFYXvbK6FUT7cCVoeVCp1aFT9eTKj7IcGdezrOBLgfGrd1bRw1qe/kR2bpA9tAtNW8UAyvw4vrmGbiBWJek0qWKlg8ojqSk9a16jMsqeHPW0lflz7lTKe1e9IKKOB5Hy8Nyj9NZGvCYRde6mWKOHF1bQRp2q4NfBKhdzhkB53gVctlrC2wMtnRmzGF/K6r5bmmae/Exr1DfsFSUsSyatBb05vljUprwfL8ypT1wLmS0KEUkivEqgBg0nu6hs9YFj+AWNdR5w8ou2jzQ+KTiwPZYmyYbohygttzkh3AYNmxAqN0vNRbrcfGCyfRY8uZP3BB9TmspCyoerD5/6ljsN3YBYcoC7qvEEnasDK+LyklC/2ZF2M26ZKigKBi6GYE1SoMQGaAGwpre/BPIvSZP55dun5DQgFvNJCngg9kwX6sEDmXMuWo0N5vzyocQxwN0fVHRCvHBOMxGUU2iaVmr0mC+DxIV0FBqmW8h/u+sXUjlQdDGGV1148eQ+9YDi4/hFab2nR7a8HL+pbZ5iDAIq0qBPqRZHo4EFdIWDUcRmgW4hiEoCVi8CYXb27rp/rHC2pBgDzBKTpt0tQTgmT+3vT7qjapj86qlnqiSyCtVk8zbXNfPbCv396k9+eEevRsJjrDoDPKLppAwGGoZBelPTyS9R0orA5TvHsUtwn0ovLcfKztwtaYJc2uCTUA7lmkb3Y3sKgP4naq7CD6ddp+7nYi0LD4xk6Pu6qbjwRpq1mhOSos/gMSOUXcpMB3VBj4B9eh7+RA80W+dzuWXLpkX4qkZhkFeF/PweXuQFfR6CBsHd/BsaA4kQZPSvHayZ4Mfg5IfWLm3xot5R/jdRb0MHrkBcoE1zApyZxH39WdP0dobXqbz/qYCJICLwbvVxtg2s/qDOCpfvA+X8nNdeJ1r+VHSvod47iqMdlUoYQKFxxkgm+0riSiFM3xM0bj2wkNNUnUmtqCg9ReaZy5GdXv6UBju4vLu4bDGizPqY5LdI+RR3te+mDNehY0IOFhpGVXUxfRnAko5UBnfpgcHcxnmYQGuVI2SOmgfjNqo6b3Zei+LFV1tORETMQG2l3fd0a/rGGEQPFIvAR10uKk1auyibsc1Xa+xhj1tlhuRBBePGStB17MoZ4zWZhqESPp7paXaadJBo66l58+g810RXkkLE4tKPY3vURLlp7tC2Po3Ce0ATlF3qVaxOCaWIGey+l4+cN1AHEQdC4aF5HquQOtSGgi+5OdaajHgCFZAwFj5mlpnfTDJzKPKWxHx8tRh0o1IuA3CgHQkXlkW2Qpe6I+kxU7TAJkX4amxoQWhAJWxrCXNulBoz67V/X+Y5DEkizeGdBxaGEBCTb3DVZwIowomxqCAqVtIietUNdrHH0rBsCBqMq3W8McoUVNuNuEx/1WRywRqyhZfPw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB5488.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8018397e-b4af-4f6f-06fd-08da2473d1e9 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2022 15:21:48.7426 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eCsHHgvIqzUCGBwsoFNQpjxMRfVDSMfmzbN58MydVrUqN+677wt7Dy9wmWYUrr4CIGQL11hjhLMN84x0EiaPXg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR10MB1350 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486, 18.0.858 definitions=2022-04-22_04:2022-04-22, 2022-04-22 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 malwarescore=0 suspectscore=0 spamscore=0 mlxlogscore=999 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2204220068 X-Proofpoint-GUID: 40dVpl7-1GQKafZVHQ_uo7US6TSIpgWy X-Proofpoint-ORIG-GUID: 40dVpl7-1GQKafZVHQ_uo7US6TSIpgWy X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > Michael Heerdegen writes: >=20 > > I think something very similar is provided by map.el: `map-into'. >=20 > The discussion then went onto how to specify parameters to > make-hash-table, and I see that this is fixed now like this: >=20 > (map-into '((1 . 3)) '(hash-table :test eql)) >=20 > So there doesn't seem to be anything further to do here, and I'm > therefore closing this bug report. IOW, you ignored the entire thread. The bug is NOT about "how to specify parameters to make-hash-table". Yet another won't-fix.