Re: seq.el and the complexity of Emacs Lisp.

[Jim Porter <jporterbugs@gmail.com>]

On 11/7/2023 2:24 AM, João Távora wrote:
> Presumably, it's good for handling custom sequence types, such as lazy
> lists.  That's a worthy goal, very worthy even, but this polymorphism comes
> at a runtime cost, of course.  And worthy as it may be, there's no use
> of that feature in the Emacs tree (as far as I can tell from quick greps),
> so it can't really be the "technical reason" for why seq.el is preloaded
> and or recommended.

I'd say this feature of seq is already in use, albeit not heavy use: 
Eshell uses some 'seq-FOO' functions in lisp/eshell/esh-var.el 
(specifically 'eshell-index-value') so that Eshell users can index into 
*any* sequence type, no matter what that type actually is.

(Careful observers will also note that 'eshell-index-value' underscores 
one of seq.el's limitations: it doesn't work with rings, so Eshell needs 
to special-case that.)

Overall, I think seq.el's abstractions are very useful, but perhaps they 
shouldn't be the only way to perform all the various algorithms they 
support. That is, seq.el is great when you want to accept any sequence 
type, but not so great if you know for sure that you have (say) a list. 
Some sort of type-annotation like Richard proposed could resolve this 
issue though: it would essentially allow us to turn what's usually a 
runtime dispatch into a compile-time dispatch. That's probably useful 
for all generic functions; not just seq.el.