From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "John Wiegley" Newsgroups: gmane.emacs.devel Subject: Re: [Request] seq-map and mapcar with arbitrary number of sequences Date: Sat, 10 Oct 2015 16:24:33 -0700 Organization: New Artisans LLC Message-ID: References: <87si5ifvvk.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1444519511 9793 80.91.229.3 (10 Oct 2015 23:25:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Oct 2015 23:25:11 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 11 01:25:06 2015 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 1Zl3Vb-0006jK-Ev for ged-emacs-devel@m.gmane.org; Sun, 11 Oct 2015 01:24:59 +0200 Original-Received: from localhost ([::1]:46662 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zl3Va-0004Vy-I9 for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2015 19:24:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36374) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zl3VK-0004Vn-Jt for emacs-devel@gnu.org; Sat, 10 Oct 2015 19:24:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zl3VH-00059V-ER for emacs-devel@gnu.org; Sat, 10 Oct 2015 19:24:42 -0400 Original-Received: from mail-pa0-x22e.google.com ([2607:f8b0:400e:c03::22e]:34609) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zl3VH-00059K-9G for emacs-devel@gnu.org; Sat, 10 Oct 2015 19:24:39 -0400 Original-Received: by padhy16 with SMTP id hy16so119384849pad.1 for ; Sat, 10 Oct 2015 16:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:in-reply-to:date:organization:message-id :references:user-agent:mail-followup-to:mime-version:content-type; bh=AvgQumwY3eRiIoQG1LPpRrPK/X0/pqB6c8AAUr+WHyQ=; b=QWCFgyb2CEbFflG+xSS2/RKb8vna5lT3XOYtXK5UWtVIH0rCqr0NNKFUJkgGzOrxnn ME+vXNcF+MCCOLiUcwVCe9kW3y2Jktrkg9a/Ph3bTOwZmAN9PpfTSdF3WJVtgV5Irlyc 2SaKtD6VY+isolkhkB1cDlLa8iWYMZU1NEa7ZlSIzvqGOVZrkKA6+FMNTdWgX6aBMANg p3307NKcZ4TIqOznuazAqa7WZXDcNXE2pm0SXYQL27GxBKCiqbyuCdOtAq/t+iKAJsR3 FVcCRvy7415LmjCk3I9sLeoWPtzcYZNsJvQoFXdXESqHACBXA/d9N97ozKWWDNTD+rF+ E10Q== X-Received: by 10.68.88.130 with SMTP id bg2mr18165244pbb.38.1444519478570; Sat, 10 Oct 2015 16:24:38 -0700 (PDT) Original-Received: from Vulcan.local (76-234-68-79.lightspeed.frokca.sbcglobal.net. [76.234.68.79]) by smtp.gmail.com with ESMTPSA id ce3sm10091117pbb.35.2015.10.10.16.24.36 for (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 10 Oct 2015 16:24:37 -0700 (PDT) Original-Received: by Vulcan.local (Postfix, from userid 501) id 28A3BF2817ED; Sat, 10 Oct 2015 16:24:36 -0700 (PDT) In-Reply-To: (Artur Malabarba's message of "Sat, 10 Oct 2015 22:53:20 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) Mail-Followup-To: emacs-devel@gnu.org X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::22e 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:191186 Archived-At: >>>>> Artur Malabarba writes: > Yes. Supporting this on mapc and mapcar should not incur a performance cost on > the single seq version. I figured the c code for these functions could just > check if the &rest argument is nil, and then use the current (single seq) > implementation. > If this single conditional imposes a noticeable overhead we can optimise it > out with a compiler macro too (I think). The main reason I'd like it to be zero cost is that, once the change is made, there will be zero users of it. All existing code uses a single list, and it will be some time before authors feel confident enough in breaking backwards compatibility to start using multiple lists. So for a few years, at least, there will be no benefit except the knowledge that consistency has been improved. The gain is too small for it to be worth a real cost. John