From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Wilfred Hughes Newsgroups: gmane.emacs.devel Subject: Re: RFC: make maphash return a list Date: Sun, 5 May 2013 01:06:23 +0100 Message-ID: References: <87txmjcnz5.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec54859e0f43d2704dbed5b0b X-Trace: ger.gmane.org 1367712415 27919 80.91.229.3 (5 May 2013 00:06:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 May 2013 00:06:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 05 02:06:54 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UYmTd-0004Ak-Q4 for ged-emacs-devel@m.gmane.org; Sun, 05 May 2013 02:06:54 +0200 Original-Received: from localhost ([::1]:46318 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYmTd-0007Wd-70 for ged-emacs-devel@m.gmane.org; Sat, 04 May 2013 20:06:53 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59913) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYmTY-0007WX-Aq for emacs-devel@gnu.org; Sat, 04 May 2013 20:06:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UYmTU-0007LR-As for emacs-devel@gnu.org; Sat, 04 May 2013 20:06:48 -0400 Original-Received: from mail-vc0-f169.google.com ([209.85.220.169]:57346) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYmTU-0007LB-7I for emacs-devel@gnu.org; Sat, 04 May 2013 20:06:44 -0400 Original-Received: by mail-vc0-f169.google.com with SMTP id gd11so2365542vcb.0 for ; Sat, 04 May 2013 17:06:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=aHmyrPjGOakdcvtiUAkZgSF/EtZxVGbSnu42TbvAlks=; b=na6hxI31O/esEubXVa/JJhGSFa/ZTS16WeVGaTvrIZETF0QLyQgQx9PpBY9jtMgW1w hULoXnC/Vnb0eLwNnM62L3brKsG0QHKIFGjSw2KwezYTh5oZ2Kwok3myClhjiT4APr2U +Yf3cHPumvSd3X0W+9zfbRgKZ6PKTIOCs6FKrZFaVh+ycJ3bx50goIkf0eTWpVDBOaLr p9goi9UQ6RK3TEUvcRq9/SwMgHGr0nWvcEN2hDgBSbREz2P8aDrLmMOPs1Ut9Hp2ZEHA 8HfNInZx4PxWvlOfGyPyDakNsIM8i6GL1uE8FF8UfgjTbNP7X6xxqu7O8I4kYPDxRpnw wv4g== X-Received: by 10.52.117.147 with SMTP id ke19mr4425837vdb.24.1367712403302; Sat, 04 May 2013 17:06:43 -0700 (PDT) Original-Received: by 10.58.67.104 with HTTP; Sat, 4 May 2013 17:06:23 -0700 (PDT) X-Originating-IP: [217.39.11.49] In-Reply-To: <87txmjcnz5.fsf@uwakimon.sk.tsukuba.ac.jp> X-Gm-Message-State: ALoCoQkADg9eBzhhwBpsHpZcZAzMgtVGyTtrjXGWoK6LmLg0sGIZN0irtgthlpxjqHDIpkr5wrmy X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.220.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:159306 Archived-At: --bcaec54859e0f43d2704dbed5b0b Content-Type: text/plain; charset=UTF-8 > maphash is nice because it doesn't cons a list. So you're saying that maphash returning nil is a desirable property because it doesn't build a list if you don't want it? OK, I understand. I think it might be helpful for the docstring of maphash to say 'for side effects only' the same way mapc does. My (incorrect) intuition was that any mapFOO function would return a sequence unless otherwise stated. > (defun choose-name-to-taste (callable table) > "Left as an exercise for the reader." > (let ((retlist nil)) > (maphash (lambda (key value) > (setq retlist (cons (funcall callable key value) retlist))) > table)) > retlist)) Yep, exactly. I don't want to turn this into bikeshedding -- I only felt it was a nice to have, and of course I can build a list myself. Since both mapcar and mapc exist in core Emacs, would it be worthwhile to have a blessed chose-name-to-taste implementation in core? > Isn't this [adding functionality to loop] the right place to improve elisp? That's an excellent idea, I'll try to put together a patch for that. Thanks for your feedback, I appreciate it. Wilfred --bcaec54859e0f43d2704dbed5b0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> maphash is nice because it doesn't= cons a list.

So you're saying that maphash returning nil = is a desirable property because it doesn't build a list if you don'= t want it? OK, I understand. I think it might be helpful for the docstring = of maphash to say 'for side effects only' the same way mapc does. M= y (incorrect) intuition was that any mapFOO function would return a sequenc= e unless otherwise stated.

> (defun choose-name-to-taste (callable table)
> =C2=A0 "Left as an exercise for the reader."
> =C2=A0 (let ((retlist nil))
>=C2=A0 =C2=A0 (maphash (lambda (key= value)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 (setq retlist (c= ons (funcall callable key value) retlist)))
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0=C2=A0 table))
>=C2=A0 =C2=A0 retlist))

Yep, exactly. I don't want to turn this into bikeshedding -- I on= ly felt it was a nice to have, and of course I can build a list myself. Sin= ce both mapcar and mapc exist in core Emacs, would it be worthwhile to have= a blessed chose-name-to-taste implementation in core?

> Isn't this [adding functionality to loop] the right place to i= mprove elisp?

That's an excellent idea, I'll try = to put together a patch for that.

Thanks for your f= eedback, I appreciate it.

Wilfred
--bcaec54859e0f43d2704dbed5b0b--