emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What's missing in ELisp that makes people want to use cl-lib?


From: Augusto Stoffel
Subject: Re: What's missing in ELisp that makes people want to use cl-lib?
Date: Thu, 16 Nov 2023 15:36:32 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

On Thu, 16 Nov 2023 at 00:28, João Távora wrote:

> I don't think you just skip the seq-do generic like that :-)

Of course you don't.  This _is not_ a patch submission :-).

What I'm pointing out is that the seq-doseq macro is probably the most
consequential bit regarding performance.  If you use a mapc and closures
where you could use a simple dolist, performance will obviously suffer.

There exist extensible macros in Emacs (such as pcase), so adding some
kind dynamic dispatch for seq-doseq should be possible.  Barring that,
one would have to define list-specific methods for 8 generic functions
that use seq-doseq, which is also not unfeasible.

> That breaks any sequence type based on lists.  This is exactly the
> problem I was raising with too-many-generic interfaces, btw.

Good point.  IMO you just can't have both lists and "types based on
lists" to work together properly; if we defined a method for
seq-difference on lists, the issue would be the same (I guess that's the
caveat you raised regarding Dmitri's patch).

I don't see much appeal in user-defined seq types (as opposed to dealing
uniformly with lists, vectors and strings, which is mildly useful).  In
any case, the user always has the options to wrap a struct or class
around their custom list types.  So "sequence types based on lists"
could just be disallowed (I suppose this was part of those long
discussions, which I admit I didn't follow closely.)

> Try Dmitry's patch instead, the one containing seq-difference-3.

That approach is fine, but it only addresses one function at a time.
(If we go that way, I suggest starting by the most useful ones:
seq-filter, seq-some and seq-reduce.)

>> I for one like the simple aesthetics of seq.
>
> Are you familiar with the cl-lib.el "aesthetics"?

Yes.

> The simple versions argumentless versions are no uglier than seq's,

As far as names are concerned, cl-remove-if-not is uglier than
seq-filter.

> cl-some vs seq-some
> cl-every vs set-every-p
> cl-set-difference vs seq-intersection

cl-set-difference is an operation on lists, not sets...

> What specific thing do you like in seq.el that you don't
> find in the sequence functions of cl-lib.el?

Like other people already said, it's more about what you _don't_ find in
seq.  The seq API is much more straightforward than cl-lib's.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]