GNU bug report logs - #21782
25.0.50; New functions nfront/front

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21782 in the body.
You can then email your comments to 21782 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <f92capac <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.50; New functions nfront/front
Date: Thu, 29 Oct 2015 18:57:59 +0900 (JST)

[Message part 1 (text/plain, inline)]

In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.23)
 of 2015-10-29
Repository revision: 07830c3d5c801d7d55622215b46ba692c6afa1d2


I found very useful to define one function returning:
(nreverse (last (nreverse list) N))
(for a given list and integer N)

Maybe its already defined somewhere, but i cannot find it.

Examples of the new function:
(let ((ltest '( 1 2 3 4 5 6)))
  (nfront ltest 3))
(1 2 3)

(let ((ltest '( 1 2 3 4 5 6)))
  (nfront ltest 1))
(1)

(let ((ltest '( 1 2 3 4 5 6)))
  (nfront ltest 20))
(1 2 3 4 5 6)

(let ((ltest '( 1 2 3 4 5 6)))
  (nfront ltest))
(1 2 3 4 5 6)

[subr.patch (text/plain, attachment)]

Message #8 received at 21782 <at> debbugs.gnu.org (full text, mbox):

From: Artur Malabarba <bruce.connor.am <at> gmail.com>
To: Tino Calancha <f92capac <at> gmail.com>
Cc: 21782 <at> debbugs.gnu.org
Subject: Re: bug#21782: 25.0.50; New functions nfront/front
Date: Thu, 29 Oct 2015 15:25:53 +0000

[Message part 1 (text/plain, inline)]

Hi Tino, thanks for the submission.

I think this is already available in core as seq-take, from the seq
package.

[Message part 2 (text/html, inline)]

Message #11 received at 21782 <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <f92capac <at> gmail.com>
To: 21782 <at> debbugs.gnu.org
Cc: Artur Malabarba <bruce.connor.am <at> gmail.com>
Subject: Re: bug#21782: 25.0.50; New functions nfront/front
Date: Fri, 30 Oct 2015 10:25:31 +0900 (JST)

[Message part 1 (text/plain, inline)]

> I think this is already available in core as seq-take, from the seq package.

Thank you, you are right. Indeed, I found seq-take very nice:
its more general because apply to sequences.
There is one small difference: seq-take has no optional arguments.

In addition, seq.el need to be loaded by the user. Yeah, not a big
deal, but IMO such fundamental operation on a list as nfront 
implement, deserve to be available at the starting of the session.
Putting a dedicated function in subr.el we save to load many stuff from
seq.el that maybe we dont need.

I would like nfront/front would behave as nbutlast/butlast concerning
the N argument:
*) N nil giving same output as N = 1.
*) N <= 0 return the full list.
(I choose the name of the function to somehow reflect such symmetry).

I have modified my patch to accomplish such behaviour.

With the new patch

(let ((ltest '(1 2 3 4 5 6)))
  (nbutlast ltest nil))
(1 2 3 4 5)
(let ((ltest '(1 2 3 4 5 6)))
  (nfront ltest nil))
(1)
(require 'seq)
(let ((ltest '(1 2 3 4 5 6)))
  (seq-take ltest nil)); error: second argument is not optional

(let ((ltest '(1 2 3 4 5 6)))
  (nbutlast ltest 0))
(1 2 3 4 5 6)
(let ((ltest '(1 2 3 4 5 6)))
  (nfront ltest 0))
(1 2 3 4 5 6)
(let ((ltest '(1 2 3 4 5 6)))
  (seq-take ltest 0))
nil

(let ((ltest '(1 2 3 4 5 6)))
  (nbutlast ltest -1))
(1 2 3 4 5 6)
(let ((ltest '(1 2 3 4 5 6)))
  (nfront ltest -1))
(1 2 3 4 5 6)
(let ((ltest '(1 2 3 4 5 6)))
  (seq-take ltest -1))
nil

(let ((ltest '(1 2 3 4 5 6)))
  (nbutlast ltest 20))
nil
(let ((ltest '(1 2 3 4 5 6)))
  (nfront ltest 20))
(1 2 3 4 5 6)
(let ((ltest '(1 2 3 4 5 6)))
  (seq-take ltest 20))
(1 2 3 4 5 6)

[subr-2.patch (text/plain, attachment)]

Message #14 received at 21782 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Tino Calancha <f92capac <at> gmail.com>
Cc: 21782 <at> debbugs.gnu.org
Subject: Re: bug#21782: 25.0.50; New functions nfront/front
Date: Thu, 29 Oct 2015 21:33:59 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

ISTR there are traditional names for those functions.
I don't remember what they were, but if we are going to add them,
we should use their traditional names.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Message #17 received at 21782 <at> debbugs.gnu.org (full text, mbox):

From: "Constantino Calancha" <f92capac <at> gmail.com>
To: 21782 <at> debbugs.gnu.org
Cc: rms <at> gnu.org
Subject: Re: bug#21782: 25.0.50; New functions nfront/front
Date: Fri, 30 Oct 2015 10:41:55 +0900

> ISTR there are traditional names for those functions.
> I don't remember what they were, but if we are going to add them,
> we should use their traditional names.

Sure, i also prefer keep their original names.

Considering my previous example: i disagree with myself about
nfront being consistent with nbutlast.

nfront should return nil when N<= 0 as seq-take does.
Only when N is nil is when we provide the sensible default N=1 as nbutlast.

Message #20 received at 21782 <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <f92capac <at> gmail.com>
To: 21782 <at> debbugs.gnu.org
Cc: "C. Calancha" <f92capac <at> gmail.com>
Subject: Re: bug#21782: 25.0.50; New functions nfront/front
Date: Fri, 30 Oct 2015 11:10:47 +0900 (JST)

[Message part 1 (text/plain, inline)]

The new patch has more sense to me.

I correct my previous wish about the func. behaviour with respect N:
*) N nil give same output as N = 1.
*) N <= 0 return nil.


(let ((ltest '(1 2 3 4 5 6)))
  (nfront ltest 0))
nil
(let ((ltest '(1 2 3 4 5 6)))
  (nfront ltest -1))
nil
(let ((ltest '(1 2 3 4 5 6)))
  (nfront ltest 3))
(1 2 3)
(let ((ltest '(1 2 3 4 5 6)))
  (nfront ltest))
(1)
(let ((ltest '(1 2 3 4 5 6)))
  (nfront ltest 100))
(1 2 3 4 5 6)

[subr-3.patch (text/plain, attachment)]

Message #23 received at 21782 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Tino Calancha <f92capac <at> gmail.com>
Cc: Artur Malabarba <bruce.connor.am <at> gmail.com>, 21782 <at> debbugs.gnu.org
Subject: Re: bug#21782: 25.0.50; New functions nfront/front
Date: Fri, 30 Oct 2015 03:38:33 +0100

Tino Calancha <f92capac <at> gmail.com> writes:

> +    (nreverse (last (nreverse list) n))))

Isn't this horribly inefficient?  It would be better to use `nthcdr' or
a simple loop.

Dunno if this should be in the core, I think having this functionality
in "seq.el" is a good place.


Michael.

Message #26 received at 21782 <at> debbugs.gnu.org (full text, mbox):

From: "Constantino Calancha" <f92capac <at> gmail.com>
To: "21782 <at> debbugs.gnu.org" <21782 <at> debbugs.gnu.org>
Cc: f92capac <at> gmail.com
Subject: Re: bug#21782: 25.0.50; New functions nfront/front
Date: Fri, 30 Oct 2015 11:53:30 +0900

Im sorry Michael, but i dont see your point: do you mean the fact to call
nreverse twice?
nreverse is in fact very efficient;
and last already use nthcdr in its implementation.

Please elaborate more.

As i mentioned, they are not exactly the same function as seq-take.

Why i need to pollute my global space with all seq.el just to use this
fundamental operation on a list?

I we want this in the core, we may also consider to implement such
functionality in
src/fns.c

Tino

On Fri, 30 Oct 2015 11:38:33 +0900, Michael Heerdegen  
<michael_heerdegen <at> web.de> wrote:

> Tino Calancha <f92capac <at> gmail.com> writes:
>
>> +    (nreverse (last (nreverse list) n))))
>
> Isn't this horribly inefficient?  It would be better to use `nthcdr' or
> a simple loop.
>
> Dunno if this should be in the core, I think having this functionality
> in "seq.el" is a good place.
>
>
> Michael.

Message #29 received at 21782 <at> debbugs.gnu.org (full text, mbox):

From: Artur Malabarba <bruce.connor.am <at> gmail.com>
To: Tino Calancha <f92capac <at> gmail.com>
Cc: 21782 <at> debbugs.gnu.org
Subject: Re: bug#21782: 25.0.50; New functions nfront/front
Date: Fri, 30 Oct 2015 09:45:57 +0000

[Message part 1 (text/plain, inline)]

On 30 Oct 2015 2:53 am, "Constantino Calancha" <f92capac <at> 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/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.

[Message part 2 (text/html, inline)]

Message #32 received at 21782 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Petton <nicolas <at> petton.fr>
To: Constantino Calancha <f92capac <at> gmail.com>,
 "21782\@debbugs.gnu.org" <21782 <at> debbugs.gnu.org>
Cc: f92capac <at> gmail.com
Subject: Re: bug#21782: 25.0.50; New functions nfront/front
Date: Fri, 30 Oct 2015 11:03:50 +0100

[Message part 1 (text/plain, inline)]

Constantino Calancha <f92capac <at> gmail.com> writes:

Hi,

> As i mentioned, they are not exactly the same function as seq-take.

I think adding these functions would mostly be code duplication.  Please
bear in mind that seq.el was written to provide a good built-in sequence
library in Emacs.  If seq-take doesn't provide exactly what you need,
you could propose a patch to improve it instead.

> Why i need to pollute my global space with all seq.el just to use this
> fundamental operation on a list?

All functions in seq.el are prefixed, so there's no global namespace
polluting, and I consider many functions provided by seq.el to be
fundamental operations on sequences.

Also, seq.el is not pre-loaded today because it's a new library, so it
is not widely used in Emacs yet, but that could change in the future.

Nico

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 21782 <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <f92capac <at> gmail.com>
To: 21782 <at> debbugs.gnu.org
Cc: Tino Calancha <f92capac <at> gmail.com>, 21782 <at> debbugs.gnu.org
Subject: Re: bug#21782: 25.0.50; New functions nfront/front
Date: Fri, 30 Oct 2015 19:10:00 +0900 (JST)

Thank you.
I agree with your 3 points.
1) Clearly replicate functionality
2) Yes, the prefix prevent to pollute.
3) Agree.

My main concern is why seq-take is not auloaded at the start of the 
session. Its natural to have loaded such function always.

Anyway thank you very much.

On Fri, 30 Oct 2015, Artur Malabarba wrote:

> 
> On 30 Oct 2015 2:53 am, "Constantino Calancha" <f92capac <at> 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/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.
> 
> 
>

Message #38 received at 21782 <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <f92capac <at> gmail.com>
To: Nicolas Petton <nicolas <at> petton.fr>
Cc: Constantino Calancha <f92capac <at> gmail.com>,
 "21782 <at> debbugs.gnu.org" <21782 <at> debbugs.gnu.org>
Subject: Re: bug#21782: 25.0.50; New functions nfront/front
Date: Fri, 30 Oct 2015 19:11:07 +0900 (JST)

> Also, seq.el is not pre-loaded today because it's a new library, so it
> is not widely used in Emacs yet, but that could change in the future.

I see. I think is worth to give it a try to this lib.
Thank you.

Message #41 received at 21782 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Constantino Calancha <f92capac <at> gmail.com>
Cc: "21782 <at> debbugs.gnu.org" <21782 <at> debbugs.gnu.org>
Subject: Re: bug#21782: 25.0.50; New functions nfront/front
Date: Fri, 30 Oct 2015 15:09:10 +0100

"Constantino Calancha" <f92capac <at> gmail.com> writes:

> Im sorry Michael, but i dont see your point: do you mean the fact to
> call nreverse twice?  nreverse is in fact very efficient; and last
> already use nthcdr in its implementation.

`nreverse` efficiently does what is supposed to do, yes.  But it is
O(l), where l is the length of the list arg.

In addition, the newly created `nreverse'd list must be garbage
collected.

The `copy-sequence' call in `front' is bad for the same reason.

OTOH nfront can be implemented in O(n), where n is the number argument
to nfront.


Michael.

Message #44 received at 21782 <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <f92capac <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Constantino Calancha <f92capac <at> gmail.com>,
 "21782 <at> debbugs.gnu.org" <21782 <at> debbugs.gnu.org>
Subject: Re: bug#21782: 25.0.50; New functions nfront/front
Date: Sat, 31 Oct 2015 03:06:40 +0900 (JST)

>
> `nreverse` efficiently does what is supposed to do, yes.  But it is
> O(l), where l is the length of the list arg.
>
> In addition, the newly created `nreverse'd list must be garbage
> collected.
>
> The `copy-sequence' call in `front' is bad for the same reason.
>
> OTOH nfront can be implemented in O(n), where n is the number argument
> to nfront.

Thank you Michael for the detail answer. I appreciate it a lot.
Now i see clearly what you mean.

For all the people:
Efficiency implementations are very important, almost as important as 
have things available.
One emacs user starting one session has no available seq-take. That is
the first thing to care, efficiency comes later.

Many users learn the lenguage autocompleting in the minibuffer. If it is
not loaded the least people will realize such functions you are 
developping do exists. We develop tools to be used, not ust to be nice.

IMOP, fundamental operations should be loaded by default. If this is not 
the case, that means the function should not be located in its corrent 
location: fair and simple.

Please, consider make this fundamental operation being loaded at the 
beginning. Thanks.
I finish here because i start to repeat myself. Thank you for the very 
nice chat; it has being very instructive for me and i enjoied very much.

Message #47 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: gnu-emacs-bug <at> moderators.isc.org
Subject: Re: bug#21782: 25.0.50; New functions nfront/front
Date: Sat, 31 Oct 2015 22:44:55 +0000 (UTC)

Hello, Richard.

Richard Stallman <rms <at> gnu.org> wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

> ISTR there are traditional names for those functions.
> I don't remember what they were, but if we are going to add them,
> we should use their traditional names.

How about `firstn':

"firstn n list
 Returns a list of length _n_, whose elements are the first _n_ elements
 of _list_.  if _list_ is fewer than _n_ elements long, the remaining
 elements of the list are ni."

[ Lisp Machine Manual, Sixth Edition, System Version 99, June 1984, by
  Richard Stallman, Daniel Weinreb and David Moon ]

> -- 
> Dr Richard Stallman
> President, Free Software Foundation (gnu.org, fsf.org)
> Internet Hall-of-Famer (internethalloffame.org)
> Skype: No way! See stallman.org/skype.html.

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #52 received at 21782-done <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <tino.calancha <at> gmail.com>
To: 21782-done <at> debbugs.gnu.org
Subject: Re: bug#21782: 25.0.50; New functions nfront/front
Date: Thu, 18 May 2017 13:08:57 +0900

Tino Calancha <f92capac <at> gmail.com> writes:


> I found very useful to define one function returning:
> (nreverse (last (nreverse list) N))
> (for a given list and integer N)
>
> Maybe its already defined somewhere, but i cannot find it.
seq-take does the same thing, so i am closing this report.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.