unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* [Request] seq-map and mapcar with arbitrary number of sequences
@ 2015-10-10  7:24 bruce.connor.am
  2015-10-10 17:47 ` John Wiegley
  0 siblings, 1 reply; 12+ messages in thread
From: bruce.connor.am @ 2015-10-10  7:24 UTC (permalink / raw)
  To: emacs-devel, Nicolas Petton

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

The basic map operation in Common lisp, Clojure, and cl-lib all support
receiving an arbitrary number of sequences. I think it makes sense for
seq-map to do that too.

Furthermore, if anyone feels up to the task, I think it would make sense
for the builtin mapc and mapcar too.

Best,
Artur

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Request] seq-map and mapcar with arbitrary number of sequences
  2015-10-10  7:24 [Request] seq-map and mapcar with arbitrary number of sequences bruce.connor.am
@ 2015-10-10 17:47 ` John Wiegley
  2015-10-10 17:58   ` David Kastrup
                     ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: John Wiegley @ 2015-10-10 17:47 UTC (permalink / raw)
  To: emacs-devel

>>>>>   <bruce.connor.am@gmail.com> writes:

> Furthermore, if anyone feels up to the task, I think it would make sense for
> the builtin mapc and mapcar too.

Those two functions are used in a large number of places. Adding support for a
"&rest seqs" argument rather than "seq" could impact performance, as it now
has to walk a one-element seqs to get the seq it had directly before. I
believe it would add another cons cell to the memory footprint, to package the
argument?

I'm fine with low-level functions preferring simplicity, since we have cl-lib
to provide higher-level versions that does not.

John



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Request] seq-map and mapcar with arbitrary number of sequences
  2015-10-10 17:47 ` John Wiegley
@ 2015-10-10 17:58   ` David Kastrup
  2015-10-10 20:10     ` John Wiegley
  2015-10-11 20:51   ` Richard Stallman
  2015-10-13 12:42   ` David Kastrup
  2 siblings, 1 reply; 12+ messages in thread
From: David Kastrup @ 2015-10-10 17:58 UTC (permalink / raw)
  To: emacs-devel

"John Wiegley" <johnw@newartisans.com> writes:

>>>>>>   <bruce.connor.am@gmail.com> writes:
>
>> Furthermore, if anyone feels up to the task, I think it would make sense for
>> the builtin mapc and mapcar too.
>
> Those two functions are used in a large number of places. Adding support for a
> "&rest seqs" argument rather than "seq" could impact performance, as it now
> has to walk a one-element seqs to get the seq it had directly before. I
> believe it would add another cons cell to the memory footprint, to package the
> argument?
>
> I'm fine with low-level functions preferring simplicity, since we have cl-lib
> to provide higher-level versions that does not.

The byte compiler should be able to squash the difference, right?

-- 
David Kastrup



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Request] seq-map and mapcar with arbitrary number of sequences
  2015-10-10 17:58   ` David Kastrup
@ 2015-10-10 20:10     ` John Wiegley
  2015-10-10 21:53       ` Artur Malabarba
  0 siblings, 1 reply; 12+ messages in thread
From: John Wiegley @ 2015-10-10 20:10 UTC (permalink / raw)
  To: emacs-devel

>>>>> David Kastrup <dak@gnu.org> writes:

> The byte compiler should be able to squash the difference, right?

If you can demonstrate that to me, I'm sold. As long as the C code doesn't
change, and the increase in complexity vanishes at byte-compilation time, I
have no argument.

John



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Request] seq-map and mapcar with arbitrary number of sequences
  2015-10-10 20:10     ` John Wiegley
@ 2015-10-10 21:53       ` Artur Malabarba
  2015-10-10 23:24         ` John Wiegley
  0 siblings, 1 reply; 12+ messages in thread
From: Artur Malabarba @ 2015-10-10 21:53 UTC (permalink / raw)
  To: emacs-devel

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

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).
On 10 Oct 2015 9:10 pm, "John Wiegley" <johnw@newartisans.com> wrote:

> >>>>> David Kastrup <dak@gnu.org> writes:
>
> > The byte compiler should be able to squash the difference, right?
>
> If you can demonstrate that to me, I'm sold. As long as the C code doesn't
> change, and the increase in complexity vanishes at byte-compilation time, I
> have no argument.
>
> John
>
>

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Request] seq-map and mapcar with arbitrary number of sequences
  2015-10-10 21:53       ` Artur Malabarba
@ 2015-10-10 23:24         ` John Wiegley
  2015-10-11 20:36           ` Nicolas Petton
  0 siblings, 1 reply; 12+ messages in thread
From: John Wiegley @ 2015-10-10 23:24 UTC (permalink / raw)
  To: emacs-devel

>>>>> Artur Malabarba <bruce.connor.am@gmail.com> 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



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Request] seq-map and mapcar with arbitrary number of sequences
  2015-10-10 23:24         ` John Wiegley
@ 2015-10-11 20:36           ` Nicolas Petton
  2015-10-11 20:48             ` John Wiegley
  0 siblings, 1 reply; 12+ messages in thread
From: Nicolas Petton @ 2015-10-11 20:36 UTC (permalink / raw)
  To: John Wiegley, emacs-devel

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

John Wiegley <johnw@newartisans.com> writes:

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

`seq-map' could maybe have that feature though, without impacting
`mapcar'.

Nico

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Request] seq-map and mapcar with arbitrary number of sequences
  2015-10-11 20:36           ` Nicolas Petton
@ 2015-10-11 20:48             ` John Wiegley
  0 siblings, 0 replies; 12+ messages in thread
From: John Wiegley @ 2015-10-11 20:48 UTC (permalink / raw)
  To: emacs-devel

>>>>> Nicolas Petton <nicolas@petton.fr> writes:

> `seq-map' could maybe have that feature though, without impacting `mapcar'.

That's perfectly reasonable.

John



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Request] seq-map and mapcar with arbitrary number of sequences
  2015-10-10 17:47 ` John Wiegley
  2015-10-10 17:58   ` David Kastrup
@ 2015-10-11 20:51   ` Richard Stallman
  2015-10-11 21:10     ` Nicolas Petton
  2015-10-13 12:42   ` David Kastrup
  2 siblings, 1 reply; 12+ messages in thread
From: Richard Stallman @ 2015-10-11 20:51 UTC (permalink / raw)
  To: John Wiegley; +Cc: emacs-devel

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

  > Those two functions are used in a large number of places. Adding support for a
  > "&rest seqs" argument rather than "seq" could impact performance, as it now
  > has to walk a one-element seqs to get the seq it had directly before. I
  > believe it would add another cons cell to the memory footprint, to package the
  > argument?

We could add a facility to define a &rest function to specify
another function to handle the one-arg case.  That way, the simple
case now handled would be essentially as efficient as it is now,
interpreted.

Byte compiled, the optimiziation is easier since it can be done
purely inside the byte compiler.

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




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Request] seq-map and mapcar with arbitrary number of sequences
  2015-10-11 20:51   ` Richard Stallman
@ 2015-10-11 21:10     ` Nicolas Petton
  2015-10-12  9:27       ` Michael Heerdegen
  0 siblings, 1 reply; 12+ messages in thread
From: Nicolas Petton @ 2015-10-11 21:10 UTC (permalink / raw)
  To: rms, John Wiegley; +Cc: emacs-devel

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

Richard Stallman <rms@gnu.org> writes:

> We could add a facility to define a &rest function to specify
> another function to handle the one-arg case.

It's slightly off-topic, but I also often miss a function to do function
composition in Emacs-Lisp.  What about adding a `compose' function,
similar to
https://common-lisp.net/project/cl-utilities/doc/compose.html?  I'd be
glad to add it.

Nico

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Request] seq-map and mapcar with arbitrary number of sequences
  2015-10-11 21:10     ` Nicolas Petton
@ 2015-10-12  9:27       ` Michael Heerdegen
  0 siblings, 0 replies; 12+ messages in thread
From: Michael Heerdegen @ 2015-10-12  9:27 UTC (permalink / raw)
  To: emacs-devel; +Cc: Stefan Monnier

Nicolas Petton <nicolas@petton.fr> writes:

> It's slightly off-topic, but I also often miss a function to do
> function composition in Emacs-Lisp.  What about adding a `compose'
> function, similar to
> https://common-lisp.net/project/cl-utilities/doc/compose.html?  I'd be
> glad to add it.

AFAIR, Stefan didn't really want to add such higher level stuff because
Emacs is not efficient in executing it.

Michael.




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Request] seq-map and mapcar with arbitrary number of sequences
  2015-10-10 17:47 ` John Wiegley
  2015-10-10 17:58   ` David Kastrup
  2015-10-11 20:51   ` Richard Stallman
@ 2015-10-13 12:42   ` David Kastrup
  2 siblings, 0 replies; 12+ messages in thread
From: David Kastrup @ 2015-10-13 12:42 UTC (permalink / raw)
  To: emacs-devel

"John Wiegley" <johnw@newartisans.com> writes:

>>>>>>   <bruce.connor.am@gmail.com> writes:
>
>> Furthermore, if anyone feels up to the task, I think it would make sense for
>> the builtin mapc and mapcar too.
>
> Those two functions are used in a large number of places. Adding support for a
> "&rest seqs" argument rather than "seq" could impact performance, as it now
> has to walk a one-element seqs to get the seq it had directly before. I
> believe it would add another cons cell to the memory footprint, to package the
> argument?

I don't think so.  The additional &rest argument would usually be nil
which isn't a cons cell.  The argument list is almost never a Lisp list
when open-coded but rather a number of slots in the CPU stack frame (and
I think it's not even needed in the byte code stack since it would be
the job of the function call code to supply the empty &rest argument to
C).  As such, an additional cons would be quite the exception rather
than the rule.  I don't think that the additional CPU stack slot would
warrant worrying about performance.

-- 
David Kastrup



^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2015-10-13 12:42 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-10-10  7:24 [Request] seq-map and mapcar with arbitrary number of sequences bruce.connor.am
2015-10-10 17:47 ` John Wiegley
2015-10-10 17:58   ` David Kastrup
2015-10-10 20:10     ` John Wiegley
2015-10-10 21:53       ` Artur Malabarba
2015-10-10 23:24         ` John Wiegley
2015-10-11 20:36           ` Nicolas Petton
2015-10-11 20:48             ` John Wiegley
2015-10-11 20:51   ` Richard Stallman
2015-10-11 21:10     ` Nicolas Petton
2015-10-12  9:27       ` Michael Heerdegen
2015-10-13 12:42   ` David Kastrup

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).