bug#57079: 29.0.50; Performance of seq-uniq is not very good

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> But it makes sense from the viewpoint of practical requirements.  Half
> of all use cases will run much slower if we don't support this case.
> Practical requirements and efficiency are more important than a slippery
> as an eel design.

Well, history tells a different tale.

> And I see a bigger (design) problem here: as you said, there is a large
> overlap between seq.el and cl-lib.el.  Once we said we don't want to
> extend CL too much because it should be compatible with Common Lisp.

We've dropped that argument a long time ago -- it's free-for-all-time in
cl-lib.el. 

> That was one reason why seq.el had been started.  When we now say that
> we can't implement something in seq.el, something that is a practical
> need, because it already exists in cl-lib, we have a problem: we will end
> with two incomplete and half baked solutions for sequence handling.

They're both fully baked, but use different design philosophies,
catering to different audiences.  Of course I think that all seq.el
functions should have :key...  and :test-not and :start and :from-end,
but I come from a CL background.