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

[Jim Porter]

On 11/9/2023 1:20 PM, João Távora wrote:
> 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,

In fact, I was considering adding support to seq.el for generators, 
which we could consider a kind of lazy sequence. I'm not entirely sure I 
*need* it yet, but it could make a few things in Eshell easier.

For example, Eshell has a for loop. It'd be nice if you could iterate 
over an Elisp generator, or even just repeatedly call a regular function 
that returns some new value each time[1]. If seq.el supported 
generators, I *think* Eshell could just call 'seq-map' (really, we'd 
want 'seq-mapc', but that's another story), and the code would do the 
right thing. This would make it easy for Eshell for loops to iterate 
over a range of integers without having to pre-build a list of all those 
integers.

I haven't done this yet though, so it's possible there's something else 
that would throw a wrench into this. (In particular, Eshell's internals 
are a bit finicky at times, and I'm not sure how they'd interact with 
generators.)

> 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?

Currently, Eshell's use of seq.el is pretty basic, but 'seq-elt' in 
particular is nice since it automatically decides whether to use 'nth' 
or 'aref' as appropriate. I don't see any similar cl-lib function that 
would do this. This lets an Eshell user use a subscript like "$foo[1]" 
for anything that would make sense to index. (Though again, we need to 
special-case rings.)

[1] Though this would probably necessitate a "break" statement to exit 
the loop.