From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.bugs Subject: bug#21782: 25.0.50; New functions nfront/front Date: Fri, 30 Oct 2015 09:45:57 +0000 Message-ID: References: <87wpu5jd1y.fsf@web.de> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11406b625eb9ee05234f4b1a X-Trace: ger.gmane.org 1446198446 5968 80.91.229.3 (30 Oct 2015 09:47:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 30 Oct 2015 09:47:26 +0000 (UTC) Cc: 21782@debbugs.gnu.org To: Tino Calancha Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 30 10:47:15 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1Zs6H8-0000kW-Fa for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Oct 2015 10:47:10 +0100 Original-Received: from localhost ([::1]:49344 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zs6H7-00020P-Nq for geb-bug-gnu-emacs@m.gmane.org; Fri, 30 Oct 2015 05:47:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41730) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zs6H3-0001y0-9n for bug-gnu-emacs@gnu.org; Fri, 30 Oct 2015 05:47:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zs6H0-0004L0-21 for bug-gnu-emacs@gnu.org; Fri, 30 Oct 2015 05:47:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zs6Gz-0004Kv-UG for bug-gnu-emacs@gnu.org; Fri, 30 Oct 2015 05:47:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zs6Gz-0007Am-Jk for bug-gnu-emacs@gnu.org; Fri, 30 Oct 2015 05:47:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Artur Malabarba Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 Oct 2015 09:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21782 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21782-submit@debbugs.gnu.org id=B21782.144619838027524 (code B ref 21782); Fri, 30 Oct 2015 09:47:01 +0000 Original-Received: (at 21782) by debbugs.gnu.org; 30 Oct 2015 09:46:20 +0000 Original-Received: from localhost ([127.0.0.1]:45295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zs6GJ-00079s-IO for submit@debbugs.gnu.org; Fri, 30 Oct 2015 05:46:19 -0400 Original-Received: from mail-lf0-f44.google.com ([209.85.215.44]:36631) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zs6Fy-000794-BS for 21782@debbugs.gnu.org; Fri, 30 Oct 2015 05:46:17 -0400 Original-Received: by lffz202 with SMTP id z202so30517092lff.3 for <21782@debbugs.gnu.org>; Fri, 30 Oct 2015 02:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JFXos+TuPdUYVDxgCizuC4GbfnyB3Z/JWSheuzvzgcg=; b=hspMh5NFbt5NXH0KsnXI1J0Ycr6NV7qjQP7wfCrZ2mxRyRMQjH72ebRyq6XJu6YkU1 legmTFhlRJG96pSqgD7Gk9viZpqghbHk0adsEl9SI7u2DUBaaY+z1NZESZUcgN05FH6Y 6OOgqK/HMLQeB8oDjM8ayw5vTE3DOveeAs5qycjX/vKc0SindxS598ataPvCmxI/O/CC PIgXpdg9LRT+dbmpFcUbjtxG8mAg+5lZ1VfIGCDqrlFo/m91STNMLZVOOLK2nUt0ukaV KWFD1hcvhVdh2P7jzEQ6OFmVkz4ZjAMuMYRHSv/6b6Ftua3UdNp1uuf2nQB7f4IEySrO C9ZA== X-Received: by 10.25.20.97 with SMTP id k94mr2221774lfi.27.1446198357438; Fri, 30 Oct 2015 02:45:57 -0700 (PDT) Original-Received: by 10.112.91.106 with HTTP; Fri, 30 Oct 2015 02:45:57 -0700 (PDT) Original-Received: by 10.112.91.106 with HTTP; Fri, 30 Oct 2015 02:45:57 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: DUzkTQpM-_E6kEYM7ztsqK6xcWU X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:108177 Archived-At: --001a11406b625eb9ee05234f4b1a Content-Type: text/plain; charset=UTF-8 On 30 Oct 2015 2:53 am, "Constantino Calancha" wrote: > Why i need to pollute my global space with all seq.el just to use this > fundamental operation on a list? I think, overall, sticking to seq-take has a smaller cost/benefit ratio than adding nfront. I state my logic below. These points are all a little subjective. So if you disagree and think that the slider falls closer to the other side, we can wait to hear more opinions (though at least Michael seems to agree). 1. While nfront is not identical to seq-take, it's similar enough that this would just be replicating functionality, which is ultimately a maintenance burden. 2. Seq is not a huge lib, so you're not polluting that much. Furthermore, all its functions are prefixed by "seq-", so you're polluting even less. Lastly, seq was added to core specifically with the purpose of being the goto sequences lib (and it's been doing that fine), so it wouldn't make sense to circumvent it now. 3. I'm of the opinion that we should be adding namespace prefixes as much as possible. Unprefixed names pollute much more and are harder to find. In any case, thanks for the suggestion. --001a11406b625eb9ee05234f4b1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 30 Oct 2015 2:53 am, "Constantino Calancha" <= ;f92capac@gmail.com> wrote: > Why i need to pollute my global space with all seq.el just to use this=
> fundamental operation on a list?

I think, overall, sticking to seq-take has a smaller cost/be= nefit ratio than adding nfront. I state my logic below.

These points are all a little subjective. So if you disagree= and think that the slider falls closer to the other side, we can wait to h= ear more opinions (though at least Michael seems to agree).

1. While nfront is not identical to seq-take, it's simil= ar enough that this would just be replicating functionality, which is ultim= ately a maintenance burden.
2. Seq is not a huge lib, so you're not polluting that much. Furthermor= e, all its functions are prefixed by "seq-", so you're pollut= ing even less. Lastly, seq was added to core specifically with the purpose = of being the goto sequences lib (and it's been doing that fine), so it = wouldn't make sense to circumvent it now.
3. I'm of the opinion that we should be adding namespace prefixes as mu= ch as possible. Unprefixed names pollute much more and are harder to find.<= /p>

In any case, thanks for the suggestion.

--001a11406b625eb9ee05234f4b1a--