From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] sequence manipulation functions Date: Mon, 10 Nov 2014 21:20:50 -0500 Message-ID: References: <87oasmmwzt.fsf@gmail.com> <87bnolslph.fsf@gmail.com> <87zjc2dic0.fsf@gmail.com> <87ioimtzu0.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1415672496 27411 80.91.229.3 (11 Nov 2014 02:21:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Nov 2014 02:21:36 +0000 (UTC) Cc: Emacs developers To: Nicolas Petton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 11 03:21:29 2014 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 1Xo15F-0003lh-NY for ged-emacs-devel@m.gmane.org; Tue, 11 Nov 2014 03:21:29 +0100 Original-Received: from localhost ([::1]:46433 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xo15F-0000qO-7t for ged-emacs-devel@m.gmane.org; Mon, 10 Nov 2014 21:21:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44054) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xo14l-0000aM-Ju for emacs-devel@gnu.org; Mon, 10 Nov 2014 21:21:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xo14e-0004pd-4U for emacs-devel@gnu.org; Mon, 10 Nov 2014 21:20:59 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:43774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xo14e-0004pZ-0X for emacs-devel@gnu.org; Mon, 10 Nov 2014 21:20:52 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4MAOatTlRLd+sd/2dsb2JhbABcgw6DYoZ+y1MEAgKBHBcBAXyEAwEBAwFWIwULCzQSFBgNJIhLCctyAQEBAQYBAQEBHpEIB4RLBYtkhAWiN4FvhBYfgnoBAQE X-IPAS-Result: Au4MAOatTlRLd+sd/2dsb2JhbABcgw6DYoZ+y1MEAgKBHBcBAXyEAwEBAwFWIwULCzQSFBgNJIhLCctyAQEBAQYBAQEBHpEIB4RLBYtkhAWiN4FvhBYfgnoBAQE X-IronPort-AV: E=Sophos;i="5.04,797,1406606400"; d="scan'208";a="96604643" Original-Received: from 75-119-235-29.dsl.teksavvy.com (HELO pastel.home) ([75.119.235.29]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Nov 2014 21:20:50 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 3EDF0735D; Mon, 10 Nov 2014 21:20:50 -0500 (EST) In-Reply-To: <87ioimtzu0.fsf@gmail.com> (Nicolas Petton's message of "Tue, 11 Nov 2014 00:12:23 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:176731 Archived-At: >> I wonder if that's really the more useful behavior, compared to the >> "inplace" sorting of `sort', or compared to the alternative is always >> returning a new sequence, but of the same type as the `seq' argument. > I can make it return a sequence of the same type as seq. I was really just asking. But at least it seems that returning the same type will save people from having to convert the list back to an array if that's what they were after. > I don't want to sort in place though, all other functions leave seq > untouched, and I would like to keep it this way. I don't like side-effects much myself, so I'm fine with that. > How do "seq-do" and "seq-map" sound like? Good. > I'm not confortable with "seq-doseq" or something like that since I > would expect it to be a macro similar to "dolist". A dolist-style macro would also be welcome. If it could even avoid calling a function at each iteration, it would be even better. > Fair enough. One question though, if sequences.el is not preloaded, then > I guess these functions should not be documented in the manual? Why not? Just state that they need a (require 'seq) before you can use them. Stefan