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

["João Távora" <joaotavora@gmail.com>]

On Thu, Nov 9, 2023 at 9:02 PM Jim Porter <jporterbugs@gmail.com> wrote:
>
> 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.

Sure that's what seq.el does, but I see no definition of new sequence
types in the core.  Whatever those "whatever sequence" types are,
they have to be defined somewhere with implementations for a bunch of
generic functions and I see none of that in the Emacs tree (again, from
my quick greps).  Examples could be an implementation of lazy sequences
for example. So it stands to reason that there's no (obvious) reason
to preload seq.el,

Also I'm not an eshell uses and I don't understand how eshell users
benefit from this, i.e. why using any other sequence-manipulation
library, such as cl-lib.el, in esh-vars.el wouldn't  do the job just
as well for them.  Maybe you could explain?

João