bug#21782: 25.0.50; New functions nfront/front

bug#21782: 25.0.50; New functions nfront/front

[Tino Calancha]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]


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)

[-- Attachment #2: Type: text/plain, Size: 840 bytes --]

diff --git a/lisp/subr.el b/lisp/subr.el
index ea926ae..976e4fd 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -405,6 +405,19 @@ nbutlast
 	   (if (> n 0) (setcdr (nthcdr (- (1- m) n) list) nil))
 	   list))))
 
+(defun front(list &optional n)
+  "Return a copy of LIST with just the first N elements.
+If N is omitted or nil the full list is copied."
+(let ((m (length list)))
+  (if (and n (<= n 0)) list
+    (nfront (copy-sequence list) n))))
+
+(defun nfront(list &optional n)
+  "Modified LIST to remove all elements but the first N.
+If N is omitted or nil the full list is copied."
+  (if (or (null n) (and n (<= n 0))) list
+    (nreverse (last (nreverse list) n))))
+
 (defun zerop (number)
   "Return t if NUMBER is zero."
   ;; Used to be in C, but it's pointless since (= 0 n) is faster anyway because

bug#21782: 25.0.50; New functions nfront/front

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 114 bytes --]

Hi Tino, thanks for the submission.

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

[-- Attachment #2: Type: text/html, Size: 149 bytes --]

bug#21782: 25.0.50; New functions nfront/front

[Tino Calancha]

[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]


> 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)

[-- Attachment #2: Type: text/plain, Size: 1534 bytes --]

diff --git a/lisp/subr.el b/lisp/subr.el
index ea926ae..ef705eb 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -391,13 +391,15 @@ last
 (defun butlast (list &optional n)
   "Return a copy of LIST with the last N elements removed.
 If N is omitted or nil, the last element is removed from the
-copy."
+copy.
+When N is <= 0 LIST is returned."
   (if (and n (<= n 0)) list
     (nbutlast (copy-sequence list) n)))
 
 (defun nbutlast (list &optional n)
   "Modifies LIST to remove the last N elements.
-If N is omitted or nil, remove the last element."
+If N is omitted or nil, remove the last element.
+When N is <= 0 LIST is returned unmodified."
   (let ((m (length list)))
     (or n (setq n 1))
     (and (< n m)
@@ -405,6 +407,21 @@ nbutlast
 	   (if (> n 0) (setcdr (nthcdr (- (1- m) n) list) nil))
 	   list))))
 
+(defun front(list &optional n)
+  "Return a copy of LIST with just the first N elements.
+If is omitted or nil copy just the first element
+When N is <= 0 the full list is copied."
+  (if (and n (<= n 0)) list
+    (nfront (copy-sequence list) n)))
+
+(defun nfront(list &optional n)
+  "Modified LIST to remove all elements but the first N.
+If N is omitted or nil remove all but the first element
+When N is <= 0 LIST is returned unmodified."
+  (or n (setq n 1))
+  (if (<= n 0) list
+    (nreverse (last (nreverse list) n))))
+
 (defun zerop (number)
   "Return t if NUMBER is zero."
   ;; Used to be in C, but it's pointless since (= 0 n) is faster anyway because

bug#21782: 25.0.50; New functions nfront/front

[Michael Heerdegen]

Tino Calancha <f92capac@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.

bug#21782: 25.0.50; New functions nfront/front

[Constantino Calancha]

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@web.de> wrote:

> Tino Calancha <f92capac@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.

bug#21782: 25.0.50; New functions nfront/front

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]

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/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.

[-- Attachment #2: Type: text/html, Size: 1369 bytes --]

bug#21782: 25.0.50; New functions nfront/front

[Tino Calancha]

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@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.
> 
> 
>

bug#21782: 25.0.50; New functions nfront/front

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

Constantino Calancha <f92capac@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

bug#21782: 25.0.50; New functions nfront/front

[Tino Calancha]

> 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.

bug#21782: 25.0.50; New functions nfront/front

[Michael Heerdegen]

"Constantino Calancha" <f92capac@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.

bug#21782: 25.0.50; New functions nfront/front

[Tino Calancha]

>
> `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.

bug#21782: 25.0.50; New functions nfront/front

[Tino Calancha]

[-- Attachment #1: Type: text/plain, Size: 456 bytes --]


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)

[-- Attachment #2: Type: text/plain, Size: 1490 bytes --]

diff --git a/lisp/subr.el b/lisp/subr.el
index ea926ae..cde4006 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -391,13 +391,15 @@ last
 (defun butlast (list &optional n)
   "Return a copy of LIST with the last N elements removed.
 If N is omitted or nil, the last element is removed from the
-copy."
+copy.
+When N is <= 0 LIST is returned."
   (if (and n (<= n 0)) list
     (nbutlast (copy-sequence list) n)))
 
 (defun nbutlast (list &optional n)
   "Modifies LIST to remove the last N elements.
-If N is omitted or nil, remove the last element."
+If N is omitted or nil, remove the last element.
+When N is <= 0 LIST is returned unmodified."
   (let ((m (length list)))
     (or n (setq n 1))
     (and (< n m)
@@ -405,6 +407,20 @@ nbutlast
 	   (if (> n 0) (setcdr (nthcdr (- (1- m) n) list) nil))
 	   list))))
 
+(defun front(list &optional n)
+  "Return a copy of LIST with just the first N elements.
+If N is omitted or nil copy just the first element
+When N is <= 0 return nil."
+(if (or (null n) (> n 0))
+  (nfront (copy-sequence list) n)))
+
+(defun nfront(list &optional n)
+  "Modified LIST to remove all elements but the first N.
+If N is omitted or nil remove all but the first element
+When N is <= 0 return nil."
+  (or n (setq n 1))
+  (if (> n 0) (nreverse (last (nreverse list) n))))
+
 (defun zerop (number)
   "Return t if NUMBER is zero."
   ;; Used to be in C, but it's pointless since (= 0 n) is faster anyway because

bug#21782: 25.0.50; New functions nfront/front

[Richard Stallman]

[[[ 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.

bug#21782: 25.0.50; New functions nfront/front

[Constantino Calancha]

> 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.

bug#21782: 25.0.50; New functions nfront/front

[Alan Mackenzie]

Hello, Richard.

Richard Stallman <rms@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).

bug#21782: 25.0.50; New functions nfront/front

[Tino Calancha]

Tino Calancha <f92capac@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.