[Request] seq-map and mapcar with arbitrary number of sequences

[Request] seq-map and mapcar with arbitrary number of sequences

[bruce.connor.am]

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

Re: [Request] seq-map and mapcar with arbitrary number of sequences

[John Wiegley]

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

Re: [Request] seq-map and mapcar with arbitrary number of sequences

[David Kastrup]

"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

Re: [Request] seq-map and mapcar with arbitrary number of sequences

[John Wiegley]

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

Re: [Request] seq-map and mapcar with arbitrary number of sequences

[Artur Malabarba]

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

Re: [Request] seq-map and mapcar with arbitrary number of sequences

[John Wiegley]

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

Re: [Request] seq-map and mapcar with arbitrary number of sequences

[Nicolas Petton]

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

Re: [Request] seq-map and mapcar with arbitrary number of sequences

[John Wiegley]

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

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

That's perfectly reasonable.

John

Re: [Request] seq-map and mapcar with arbitrary number of sequences

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

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

Re: [Request] seq-map and mapcar with arbitrary number of sequences

[Nicolas Petton]

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

Re: [Request] seq-map and mapcar with arbitrary number of sequences

[Michael Heerdegen]

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.

Re: [Request] seq-map and mapcar with arbitrary number of sequences

[David Kastrup]

"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