|
From: | Jim Porter |
Subject: | Re: seq.el and the complexity of Emacs Lisp. |
Date: | Thu, 9 Nov 2023 13:02:50 -0800 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |