[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.
- Re: seq.el and the complexity of Emacs Lisp., (continued)
- Re: seq.el and the complexity of Emacs Lisp., Philip Kaludercic, 2023/11/06
- Re: seq.el and the complexity of Emacs Lisp., Gerd Möllmann, 2023/11/06
- Re: seq.el and the complexity of Emacs Lisp., João Távora, 2023/11/07
- Re: seq.el and the complexity of Emacs Lisp., Jim Porter, 2023/11/09
- Re: seq.el and the complexity of Emacs Lisp., João Távora, 2023/11/09
- Re: seq.el and the complexity of Emacs Lisp., Jim Porter, 2023/11/09
- Re: seq.el and the complexity of Emacs Lisp., Jim Porter, 2023/11/09
- Re: seq.el and the complexity of Emacs Lisp., João Távora, 2023/11/09
- Re: seq.el and the complexity of Emacs Lisp., Jim Porter, 2023/11/09
- Re: seq.el and the complexity of Emacs Lisp., Alan Mackenzie, 2023/11/10
- Re: seq.el and the complexity of Emacs Lisp.,
Eli Zaretskii <=
- Re: seq.el and the complexity of Emacs Lisp., Michael Heerdegen, 2023/11/10
- Re: seq.el and the complexity of Emacs Lisp., João Távora, 2023/11/10
- Re: seq.el and the complexity of Emacs Lisp., Michael Heerdegen, 2023/11/10
- Re: seq.el and the complexity of Emacs Lisp., Richard Stallman, 2023/11/07
- Re: seq.el and the complexity of Emacs Lisp., Gerd Möllmann, 2023/11/08
- Re: seq.el and the complexity of Emacs Lisp., Richard Stallman, 2023/11/07
- Re: seq.el and the complexity of Emacs Lisp., Björn Bidar, 2023/11/06
- Re: seq.el and the complexity of Emacs Lisp., Eli Zaretskii, 2023/11/06
- Re: seq.el and the complexity of Emacs Lisp., Björn Bidar, 2023/11/06
- Message not available
- Re: seq.el and the complexity of Emacs Lisp., Emanuel Berg, 2023/11/06