From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#28753: 25.3; Functions to get alist from hash table and vice versa Date: Sat, 30 Dec 2017 20:40:25 +0000 Message-ID: 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11447f10e803a2056194c245" X-Trace: blaine.gmane.org 1514666365 31821 195.159.176.226 (30 Dec 2017 20:39:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 30 Dec 2017 20:39:25 +0000 (UTC) Cc: Nicolas Petton , 28753@debbugs.gnu.org, Noam Postavsky To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 30 21:39:21 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eVNuW-0007eN-I7 for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 Dec 2017 21:39:16 +0100 Original-Received: from localhost ([::1]:39295 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eVNwU-0001ns-U3 for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 Dec 2017 15:41:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53481) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eVNwJ-0001nN-2i for bug-gnu-emacs@gnu.org; Sat, 30 Dec 2017 15:41:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eVNwF-0001vU-Vc for bug-gnu-emacs@gnu.org; Sat, 30 Dec 2017 15:41:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49478) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eVNwF-0001un-Qy for bug-gnu-emacs@gnu.org; Sat, 30 Dec 2017 15:41:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eVNwF-0007I6-4r for bug-gnu-emacs@gnu.org; Sat, 30 Dec 2017 15:41:03 -0500 X-Loop: help-debbugs@gnu.org 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: Original-Received: via spool by 28753-submit@debbugs.gnu.org id=B28753.151466644427989 (code B ref 28753); Sat, 30 Dec 2017 20:41:03 +0000 Original-Received: (at 28753) by debbugs.gnu.org; 30 Dec 2017 20:40:44 +0000 Original-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 Original-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 Original-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) In-Reply-To: <87d14uusjn.fsf@web.de> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:141627 Archived-At: --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--