emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: Re: seq.el and the complexity of Emacs Lisp.
Date: Fri, 10 Nov 2023 14:01:40 +0200

> Date: Fri, 10 Nov 2023 10:03:48 +0000
> Cc: João Távora <joaotavora@gmail.com>,
>  Gerd Möllmann <gerd.moellmann@gmail.com>,
>  Richard Stallman <rms@gnu.org>, paaguti@gmail.com, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > 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.
> 
> Please don't.  This would be yet one more unnecessary complicated
> abstraction for which future maintainers would curse you for introducing.
> I don't know what a "generator" is, exactly, but it would likely involve
> a plethora of backticks, funcalls, generic functions, and the like, all
> things which make debugging difficult, if not very difficult.
> 
> The Subject: line of this thread mentions complexity.  This is something
> we should be trying to reduce in Emacs, not increase.

IMSNHO, we should see the code, or at least its prototype, before
passing judgment on whether we like it, let alone whether we will
"curse" the author.  It sounds strange to me to read that you don't
know what a "generator" is, but you already know that you don't like
it because it will involve plethora of stuff you don't want to see in
Emacs.

(Btw, if you dislike backticks so much, why is CC Mode so full of
them?)

To Jim: if you think about extending seq.el, please also think whether
the extensions must be preloaded, or can be on a separate file, say,
seq-x.el, where the extensions will be autoloaded when needed.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]