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

[João Távora]

On Mon, Nov 13, 2023 at 8:34 AM Michael Heerdegen
<michael_heerdegen@web.de> wrote:
>
> João Távora <joaotavora@gmail.com> writes:
>
> > Maybe seq.el can be made faster too?  Who knows, but it seems
> > difficult without breaking at least some of its defgeneric-based
> > contract.
>
> Of course can it, and it is not difficult in most cases.

Go right ahead, presuming you understand the pros and cons.

> For example, `cl-some' has two code paths, while `seq-some' has only one
> that corresponds to the more general and slower one in `cl-some'.
> Nothing forbids us to add the same optimization to the `seq-some'
> algorithm.

Sure you could have seq.el require 'cl-lib.el' ;-)

Now really, sure?  What about those generic functions that you
presumably have to shortcut?  Won't it break an existing contract to users
that all of the sudden you're not calling them anymore for certain
types of sequence?  And how are you going to do this without introducing
non-destructive versions of the seq.el utils?  Isn't non-mutability
in the contract?  And wasn't it a goal here to  end up with a smaller
dictionary of such utils?  Won't it bloat up comparibly to cl-lib while
still being less versatile?  These questions might have answers, of
course, but they're not answers as trivial as you make them sound.

> These kinds of benchmarks are more or less irrelevant.

I beg to differ, I think a recommended sequence processing
function that needlessly conses and takes orders of magnitude more
time to do its job is really quite relevant.  Elisp is still a
"LISt Processing" language by and large.

But also, I have to ask: what _would_ be a relevant benchmark
to you?

Just for cl-set-{n}difference, I'm seeing significant usage
in core right now, direct _and_ indirect.  I'm not sure all
the authors, let alone users, of these packages would like
to learn that these parts of their code have suddenly become
a full order of magnitude slower, let alone users using such
things, by virtue of some cl-lib.el -> seq.el operation
as is being suggested here.

At the very least, if this idea is to go ahead, answering
all those questions about seq.el's performance and measuring
everything twice should be a prerequisite.

> seq.el is new
> while cl-lib has been tuned and optimized for decades.

No, the point is that it hasn't.  Some of the destructive versions
weren't even destructive at all!  if you take a look at my code you'll
notice I optimized cl-lib considerably in very few cases.
There's a lot more that can be optimized there.

Also it  seems that the optional keyword arguments in these
functions are  not a  cause for performance concerns at all,
at least in these cases.  So just for learning that, these
benchmarks are useful.

> Nobody has so
> far ever decidedly tried to optimize seq.el with respect to efficiency.

The seq.el file has "optimized implementation for lists section" by
tweaking the generics for lists.  I find plausible the designer of
seq.el noticed that it is still much slower to do this but wanted to
keep a specific generic function contract anyway.

IOW, there's nothing wrong with declaring "library X is slow, but
powerful".  It's just that IMO it's bad to tell people to use just
that library all the time for a class of jobs.

> So please let's avoid such benchmarking contests here unless you want to
> work on seq.el (then a bug report is a better place for discussion).
> Because it has little relevance here.

Last I checked, the title of this thread is still "What's missing
in Elisp that makes people want to use cl-lib?".

One answer among several: fast sequence functions.

So, uncomfortable as the results may be (for now at least)
for proponents of "seq.el only" or "seq.el first", as long as
there's talk of deprecating cl-lib in favour of these
alternatives, I think concrete evidence and hard numbers very
much belong to this discussion.  Surely much more useful than
many ideological considerations about what complexity is.

If they lead to an improvement of seq.el in terms of speed,
so much the better.  If they lead to improvement of seq.el in
terms of versatility (like allowing backward traversal, key functions),
even better.

Finally, please note I'm not trying to bash seq.el.  I think it
has its place -- polymorphic sequences are great, if I ever
need them -- , but its use should _also_ be discriminate, not
indiscriminate.  Same for your set.el idea: IMHO it's very welcome,
but I think it will suffer (and gain, of course) from the same
kind of tradeoffs as seq.el.


João Távora