Re: What's missing in ELisp that makes, people want to use cl-lib?

Re: What's missing in ELisp that makes, people want to use cl-lib?

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

My own mea culpa:

I've written a couple of things using cl-lib features in the past, mainly
because I came across
the cl-lib documentation and found ways of doing things that were also
present in "regular Emacs LISP". Mainly a backend for company interacting
with different intermediate LaTEX files before the texlab LSP server was
"good enough" for me. Looking at them now, I blush at the fact that I could
have written them with seq-filter & friends.

So, why did I go for cl-lib?

Honest answer: it looked fancy enough to make me try it and I'm always
trying to learn new things to keep my neurons active

Mea culpa, /PA
-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 1307 bytes --]

Re: What's missing in ELisp that makes, people want to use cl-lib?

[João Távora]

On Fri, Nov 3, 2023 at 8:22 AM Pedro Andres Aranda Gutierrez
<paaguti@gmail.com> wrote:

> Looking at them now, I blush at the fact that I could have written them with seq-filter & friends.

If anything or anyone could be blushing it's seq-filter for
reinventing a ~25 year old perfectly good wheel called
cl-remove-if.

Note it I said it could, not that it should ;-)

João

Re: What's missing in ELisp that makes, people want to use cl-lib?

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

On Fri, 3 Nov 2023 at 10:27, João Távora <joaotavora@gmail.com> wrote:

> On Fri, Nov 3, 2023 at 8:22 AM Pedro Andres Aranda Gutierrez
> <paaguti@gmail.com> wrote:
>
> > Looking at them now, I blush at the fact that I could have written them
> with seq-filter & friends.
>
> If anything or anyone could be blushing it's seq-filter for
> reinventing a ~25 year old perfectly good wheel called
> cl-remove-if.
>
> Note it I said it could, not that it should ;-)
>
> João
>

<LoL> ;-)
/PA

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 1425 bytes --]

Re: What's missing in ELisp that makes, people want to use cl-lib?

[Gerd Möllmann]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> So, why did I go for cl-lib? 
>
> Honest answer: it looked fancy enough to make me try it and I'm always
> trying to learn new things to keep my neurons active
>
> Mea culpa, /PA

The reason I will not use seq.el or map.el in the forseeable future is
quite simple: I haven't ever needed an abstraction over sequence types
using generic functions, and I never have CPU cycles to give away for
free.

Re: What's missing in ELisp that makes, people want to use cl-lib?

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: emacs-devel <emacs-devel@gnu.org>
> Date: Fri, 03 Nov 2023 14:37:14 +0100
> 
> The reason I will not use seq.el or map.el in the forseeable future is
> quite simple: I haven't ever needed an abstraction over sequence types
> using generic functions, and I never have CPU cycles to give away for
> free.

What prevents us from implementing in seq.el methods for specific
types of sequences?  AFAIU, the only reason we didn't is because no
one has yet came up with important situations where the generics in
seq.el are not performant enough.

Re: What's missing in ELisp that makes, people want to use cl-lib?

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: emacs-devel <emacs-devel@gnu.org>
>> Date: Fri, 03 Nov 2023 14:37:14 +0100
>> 
>> The reason I will not use seq.el or map.el in the forseeable future is
>> quite simple: I haven't ever needed an abstraction over sequence types
>> using generic functions, and I never have CPU cycles to give away for
>> free.
>
> What prevents us from implementing in seq.el methods for specific
> types of sequences?

I won't :-).

> AFAIU, the only reason we didn't is because no
> one has yet came up with important situations where the generics in
> seq.el are not performant enough.

I don't get that line of reasoning, sorry. The Elisp manual kind of
advertises its abstraction over sequence type, you kind of say it is
isn't needed because it's kind of fast enough, usually.

What I'm missing is a positive reason why to use it. I don't see one.

Re: What's missing in ELisp that makes, people want to use cl-lib?

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: paaguti@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 03 Nov 2023 16:08:09 +0100
> 
> What I'm missing is a positive reason why to use it. I don't see one.

It's preloaded.  I think this is a good reason for using it.  The fact
that it's preloaded should also say something about how the Emacs
maintainers see seq.el and its future.

Re: What's missing in ELisp that makes, people want to use cl-lib?

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: paaguti@gmail.com,  emacs-devel@gnu.org
>> Date: Fri, 03 Nov 2023 16:08:09 +0100
>> 
>> What I'm missing is a positive reason why to use it. I don't see one.
>
> It's preloaded.  I think this is a good reason for using it.

Sparing 10^-7 seconds, when cl-lib is already loaded anyway?

> The fact
> that it's preloaded should also say something about how the Emacs
> maintainers see seq.el and its future.

I don't want to hurt anyone's feelings, but that's kind of a weak
argument. And an entirely non-technical one.

Re: What's missing in ELisp that makes, people want to use cl-lib?

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: paaguti@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 03 Nov 2023 16:30:47 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> Cc: paaguti@gmail.com,  emacs-devel@gnu.org
> >> Date: Fri, 03 Nov 2023 16:08:09 +0100
> >> 
> >> What I'm missing is a positive reason why to use it. I don't see one.
> >
> > It's preloaded.  I think this is a good reason for using it.
> 
> Sparing 10^-7 seconds, when cl-lib is already loaded anyway?

These are not the only situations in Emacs.  For example, in preloaded
code.

> > The fact
> > that it's preloaded should also say something about how the Emacs
> > maintainers see seq.el and its future.
> 
> I don't want to hurt anyone's feelings, but that's kind of a weak
> argument. And an entirely non-technical one.

When we decided to preload it, the reasons were technical.  So I don't
see why the above is not a technical argument.

Re: What's missing in ELisp that makes, people want to use cl-lib?

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: paaguti@gmail.com,  emacs-devel@gnu.org
>> Date: Fri, 03 Nov 2023 16:30:47 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> >> Cc: paaguti@gmail.com,  emacs-devel@gnu.org
>> >> Date: Fri, 03 Nov 2023 16:08:09 +0100
>> >> 
>> >> What I'm missing is a positive reason why to use it. I don't see one.
>> >
>> > It's preloaded.  I think this is a good reason for using it.
>> 
>> Sparing 10^-7 seconds, when cl-lib is already loaded anyway?
>
> These are not the only situations in Emacs.  For example, in preloaded
> code.
>
>> > The fact
>> > that it's preloaded should also say something about how the Emacs
>> > maintainers see seq.el and its future.
>> 
>> I don't want to hurt anyone's feelings, but that's kind of a weak
>> argument. And an entirely non-technical one.
>
> When we decided to preload it, the reasons were technical.  So I don't
> see why the above is not a technical argument.

I'm sorry, but I think this leads nowhere. 

seq.el and the complexity of Emacs Lisp.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I looked at seq.el to try to get an idea what those functions do.  It
was difficult to get this from the doc strings, because it wasn't
explicitly stated which ones are for users and which ones are
internal.  Eventually I got somewhat of an idea. 

As for understanding the code itself, I basically couldn't the first
thing I saw used a macro `pcase-defmacro', and I have no idea what
that does.  (I generally find `pcase' cryptic and unclear, even if I
have read its documentation just before.)

Ultimately I did figure out what some of the user-facing features were
and understand what they did.  They seem clean enough -- both simpler
and more natural than the cl- sequence functions.

I expect that they are slower at run-time, because each seq- function
needs to do the generic dispatch for each call.  Is that correct?

Maybe we could speed this up by defining a function that's a no-op but
says that its argument is a list.  Using that function in the sequence
argument to a seq- function could tell all compilers to do the generic
dispatch at compile time.  It could be called `force-list' or `!list'.
There could also be `force-vector' too if it's worth the effort.

However, as regards the overall size or complexity of Emacs Lisp, it's
not a matter of comparing the seq- functions with the cl-lib functions
and the traditoinal Emacs Lisp functions and asking which is best.
That's the question you would face when deciding how to write a piece
of code.  However, as regards the language itself, what we have is
both the seq- fuctions and the traditoinal Emacs Lisp functions, with
some developers pushing the cl-lib functions into the combination.

If that continues, the complexity of Emacs Lisp will be the sum of the
three different ways or doing these things.  That is a big step for
the worse from where we started out.  The cost of these triplicated
language features affects both execution (memory usage) and human
thought (needing to know them all).

Could we replace all the cl-lib sequence function calls with seq-
calls, in core and GNU ELPA code?  Seq is simpler and cleaner, so that
would be an improvement.  We could keep cl-lib permanently for
compatibility for external code, but it would not need to be loaded
(into Emacs or your brain) very often.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> I looked at seq.el to try to get an idea what those functions do.  It
> was difficult to get this from the doc strings, because it wasn't
> explicitly stated which ones are for users and which ones are
> internal.  Eventually I got somewhat of an idea. 
>

[...]

> I expect that they are slower at run-time, because each seq- function
> needs to do the generic dispatch for each call.  Is that correct?

Yes, I believe this has been empirically verified on multiple occasions.

[...]

> Could we replace all the cl-lib sequence function calls with seq-
> calls, in core and GNU ELPA code?  Seq is simpler and cleaner, so that
> would be an improvement.  We could keep cl-lib permanently for
> compatibility for external code, but it would not need to be loaded
> (into Emacs or your brain) very often.

Cl-lib would still be used, because it provides more than just functions
to operate on sequences.  There are a number of macros (cl-flet,
cl-loop, cl-incf, ...) and functions (cl-map accepting multiple lists,
cl-subst) that are frequently used and to my recollection to not yet
have analogous replacements in seq.

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

[Gerd Möllmann]

Richard Stallman <rms@gnu.org> writes:

Can't say much about what you write before this. I wasn't there when
seq/map, pcase, or other stuff, was added, but...

> Could we replace all the cl-lib sequence function calls with seq-
> calls, in core and GNU ELPA code?  Seq is simpler and cleaner, so that
> would be an improvement.  We could keep cl-lib permanently for
> compatibility for external code, but it would not need to be loaded
> (into Emacs or your brain) very often.

...you are loosing me here. I'm still wondering what seq/map are good
for in the first place. Considering something "cleaner" is just a
feeling, isn't it? A feeling I don't share.

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

[Björn Bidar]

Richard Stallman <rms@gnu.org> writes:

> Could we replace all the cl-lib sequence function calls with seq-
> calls, in core and GNU ELPA code?  Seq is simpler and cleaner, so that
> would be an improvement.  We could keep cl-lib permanently for
> compatibility for external code, but it would not need to be loaded
> (into Emacs or your brain) very often.

But does that really make sense? Using either is somewhat subjective.
Saying lets just drop these in a sec to all package authors seems
overreaching.

You write like lets just remove cl-lib and forget that is existed.
As mentioned elsewhere cl-lib isn't just sequence functions..
It does sound again like there's someting wrong with cl-lib because it's
cl-lib.

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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: paaguti@gmail.com, emacs-devel@gnu.org
> Date: Sun, 05 Nov 2023 21:27:25 -0500
> 
> I looked at seq.el to try to get an idea what those functions do.  It
> was difficult to get this from the doc strings, because it wasn't
> explicitly stated which ones are for users and which ones are
> internal.

Our convention nowadays is that any function/variable that has 2
dashes after the prefix, in this case seq--SOMETHING, is internal, and
all the others are public.

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

[Eli Zaretskii]

> From: Björn Bidar <bjorn.bidar@thaodan.de>
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>  paaguti@gmail.com, emacs-devel@gnu.org
> Date: Mon, 06 Nov 2023 10:11:08 +0200
> 
> Saying lets just drop these in a sec to all package authors seems
> overreaching.

Richard's question was about use of cl-lib in the Emacs tree, it will
not (and cannot) affect third-party packages.

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

[Björn Bidar]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Björn Bidar <bjorn.bidar@thaodan.de>
>> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>>  paaguti@gmail.com, emacs-devel@gnu.org
>> Date: Mon, 06 Nov 2023 10:11:08 +0200
>> 
>> Saying lets just drop these in a sec to all package authors seems
>> overreaching.
>
> Richard's question was about use of cl-lib in the Emacs tree, it will
> not (and cannot) affect third-party packages.

He also mentioned about ELPA. Even if it's just the Emacs tree it does
seem overreaching unless there's a direct benefit.

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

[Emanuel Berg]

Björn Bidar wrote:

>>> Saying lets just drop these in a sec to all package
>>> authors seems overreaching.
>>
>> Richard's question was about use of cl-lib in the Emacs
>> tree, it will not (and cannot) affect third-party packages.
>
> He also mentioned about ELPA. Even if it's just the Emacs
> tree it does seem overreaching unless there's
> a direct benefit.

On the whole, changing code that works, for that to make sense
one must have a distinct improvement in mind, that is almost
beyond discussion, otherwise it isn't worth the effort to do
it, with everything negative and unexpected that can follow -
in my experience.

-- 
underground experts united
https://dataswamp.org/~incal

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

[Emanuel Berg]

Eli Zaretskii wrote:

>> I looked at seq.el to try to get an idea what those
>> functions do. It was difficult to get this from the doc
>> strings, because it wasn't explicitly stated which ones are
>> for users and which ones are internal.
>
> Our convention nowadays is that any function/variable that
> has 2 dashes after the prefix, in this case seq--SOMETHING,
> is internal, and all the others are public.

Are you only allowed to use some--private-function in the same
file where it is defined?

Even as it is actually available everywhere, just like any
some-public-function defined?

To what extent has this convention been upheld in the
Emacs source?

Maybe the byte-compiler should warn when such functions are
used from elsewhere? But maybe then people would just rename
them with a single dash instead of two? But that, by all
means, at least would uphold the convention.

-- 
underground experts united
https://dataswamp.org/~incal

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]

On Mon, Nov 06, 2023 at 10:43:49PM +0100, Emanuel Berg wrote:
> Eli Zaretskii wrote:

[...]

> > Our convention nowadays is that any function/variable that
> > has 2 dashes after the prefix, in this case seq--SOMETHING,
> > is internal, and all the others are public.
> 
> Are you only allowed to use some--private-function in the same
> file where it is defined?

You are allowed to do anything. But then, if you complain
that the function calling signature has changed from under
you, the author is allowed to tell you "told you so".

Seems like a fair deal to me.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Emanuel Berg]

tomas wrote:

>>> Our convention nowadays is that any function/variable that
>>> has 2 dashes after the prefix, in this case
>>> seq--SOMETHING, is internal, and all the others
>>> are public.
>> 
>> Are you only allowed to use some--private-function in the
>> same file where it is defined?
>
> You are allowed to do anything. But then, if you complain
> that the function calling signature has changed from under
> you, the author is allowed to tell you "told you so".
>
> Seems like a fair deal to me.

Yes, but if there is a convention in code, shouldn't one be
able to say about some piece of code, "this code sticks to the
convention"?

Also, saying that something is "internal" or "public" based on
a convention - then all the more reason to explain exactly
what the convention means - as, in terms of technology, they
are both as public, actually?

-- 
underground experts united
https://dataswamp.org/~incal

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

[Emanuel Berg]

tomas wrote:

>>> Our convention nowadays is that any function/variable that
>>> has 2 dashes after the prefix, in this case
>>> seq--SOMETHING, is internal, and all the others
>>> are public.
>> 
>> Are you only allowed to use some--private-function in the
>> same file where it is defined?
>
> You are allowed to do anything. But then, if you complain
> that the function calling signature has changed from under
> you, the author is allowed to tell you "told you so".
>
> Seems like a fair deal to me.

Do we have this kind of document?

  https://www.kernel.org/doc/html/v4.10/process/coding-style.html

Search that text for GNU and Emacs (emacs) BTW :D

-- 
underground experts united
https://dataswamp.org/~incal

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

[Harald Judt]

[-- Attachment #1.1: Type: text/plain, Size: 1271 bytes --]

Am 06.11.23 um 22:30 schrieb Emanuel Berg:
> Björn Bidar wrote:
> 
>>>> Saying lets just drop these in a sec to all package
>>>> authors seems overreaching.
>>>
>>> Richard's question was about use of cl-lib in the Emacs
>>> tree, it will not (and cannot) affect third-party packages.
>>
>> He also mentioned about ELPA. Even if it's just the Emacs
>> tree it does seem overreaching unless there's
>> a direct benefit.
> 
> On the whole, changing code that works, for that to make sense
> one must have a distinct improvement in mind, that is almost
> beyond discussion, otherwise it isn't worth the effort to do
> it, with everything negative and unexpected that can follow -
> in my experience.

That seems to be a common but unfortunate practice nowadays, that you should 
not touch code that is working, especially rooted in corporate environments. 
Every improvement to the code will make it easier to maintain in the long 
term, fighting bit-rot and inconsistencies. If you touch it and it fails, you 
simply fix it, there is nothing preventing you from making changes to the code 
again.

Harald

-- 
`Experience is the best teacher.'

PGP Key ID: 4FFFAB21B8580ABD
Fingerprint: E073 6DD8 FF40 9CF2 0665 11D4 4FFF AB21 B858 0ABD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Emanuel Berg]

Harald Judt wrote:

>>>>> Saying lets just drop these in a sec to all package
>>>>> authors seems overreaching.
>>>>
>>>> Richard's question was about use of cl-lib in the Emacs
>>>> tree, it will not (and cannot) affect
>>>> third-party packages.
>>>
>>> He also mentioned about ELPA. Even if it's just the Emacs
>>> tree it does seem overreaching unless there's
>>> a direct benefit.
>>
>> On the whole, changing code that works, for that to make
>> sense one must have a distinct improvement in mind, that is
>> almost beyond discussion, otherwise it isn't worth the
>> effort to do it, with everything negative and unexpected
>> that can follow - in my experience.
>
> That seems to be a common but unfortunate practice nowadays,
> that you should not touch code that is working, especially
> rooted in corporate environments. Every improvement to the
> code will make it easier to maintain in the long term,
> fighting bit-rot and inconsistencies. If you touch it and it
> fails, you simply fix it, there is nothing preventing you
> from making changes to the code again.

Fighting bit-rot and inconsistencies is okay if those are
small, easy and uniform to fix, and one can see a clear
benefit of doing so (be it small in size as well).

But cl-lib is huge, any action to reduce its influence will be
an equally huge effort - an effort that will seldom look the
same twice - and, worse, can anyone tell for sure what the
benefit would be again? Code that is easier to maintain?
Why exactly, and how do we even know that?

What are we going to replace cl-1, cl-2, ..., cl-n with to get
what kind of advantage-1, advantage-2, ..., advantage-n
exactly? Can anyone tell, really?

No, this whole case against cl-lib doesn't add up, sorry.

-- 
underground experts united
https://dataswamp.org/~incal

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

[João Távora]

On Mon, Nov 6, 2023 at 8:54 AM Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
>
> Richard Stallman <rms@gnu.org> writes:
>
> Can't say much about what you write before this. I wasn't there when
> seq/map, pcase, or other stuff, was added, but...
>
> > Could we replace all the cl-lib sequence function calls with seq-
> > calls, in core and GNU ELPA code?  Seq is simpler and cleaner, so that
> > would be an improvement.  We could keep cl-lib permanently for
> > compatibility for external code, but it would not need to be loaded
> > (into Emacs or your brain) very often.
>
> ...you are losing me here. I'm still wondering what seq/map are good
> for in the first place.

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.

> Considering something "cleaner" is just a
> feeling, isn't it? A feeling I don't share.

Absolutely.  I also think "cleaner" is a very weak argument.

Anyway, I think this discussion could use some data:

(require 'cl-lib)

(defun bench-seq-some (seq)
  (seq-some #'identity seq))

(defun bench-cl-some (seq)
  (cl-some #'identity seq))

(defun bench-cl-loop-list (l)
  ;; checks for some types of improper lists
  (cl-loop for e in l thereis (identity e)))

(defun bench-cl-loop-vec (v)
  (cl-loop for e across v thereis (identity e)))


(when nil
  ;; Small lists
  (let ((l (list nil nil nil nil t)))
    (benchmark-run 1000000 (bench-cl-some l))) ;; (0.179339 0 0.0)

  (let ((l (list nil nil nil nil t)))
    (benchmark-run 1000000 (bench-seq-some l))) ;; (2.726298 19
0.7982190000000031)

  (let ((l (list nil nil nil nil t)))
    (benchmark-run 1000000 (bench-cl-loop-list l))) ;; (0.29131 0 0.0)

  ;; Big lists
  (let ((l (make-list 10000000 nil)))
    (benchmark-run 1 (bench-cl-some l))) ;; (0.142612 0 0.0)

  (let ((l (make-list 10000000 nil)))
    (benchmark-run 1 (bench-seq-some l))) ;; (0.379376 0 0.0)

  (let ((l (make-list 10000000 nil)))
    (benchmark-run 1 (bench-cl-loop-list l))) ;; (0.292876 0 0.0)

  ;; Small vectors
  (let ((v (vector nil nil nil nil t)))
    (benchmark-run 1000000 (bench-cl-some l))) ;; (4.058951 53
1.6585750000000008)

  (let ((v (vector nil nil nil nil t)))
    (benchmark-run 1000000 (bench-seq-some l))) ;; (2.61798 25
0.7980089999999986)

  (let ((v (vector nil nil nil nil t)))
    (benchmark-run 1000000 (bench-cl-loop-vec v))) ;; (0.306206 0 0.0)

  ;; Big vectors
  (let ((v (make-vector 10000000 nil)))
    (benchmark-run 1 (bench-cl-some v))) ;; (1.910587 14
1.2171730000000025) (DREADFUL, EASY TO FIX?)

  (let ((v (make-vector 10000000 nil)))
    (benchmark-run 1 (bench-seq-some v))) ;; (0.33895600000000004 0 0.0)

  (let ((v (make-vector 10000000 nil)))
    (benchmark-run 1 (bench-cl-loop-vec v))) ;; (0.325975 0 0.0)


  )

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

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Mon, 06 Nov 2023 22:43:49 +0100
> 
> Eli Zaretskii wrote:
> 
> >> I looked at seq.el to try to get an idea what those
> >> functions do. It was difficult to get this from the doc
> >> strings, because it wasn't explicitly stated which ones are
> >> for users and which ones are internal.
> >
> > Our convention nowadays is that any function/variable that
> > has 2 dashes after the prefix, in this case seq--SOMETHING,
> > is internal, and all the others are public.
> 
> Are you only allowed to use some--private-function in the same
> file where it is defined?

That's the convention, yes.

> To what extent has this convention been upheld in the
> Emacs source?

It is upheld quite closely.

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

[Ihor Radchenko]

Emanuel Berg <incal@dataswamp.org> writes:

> Do we have this kind of document?
>
>   https://www.kernel.org/doc/html/v4.10/process/coding-style.html

Section "D.1 Emacs Lisp Coding Conventions" in Elisp manual.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Tue, 07 Nov 2023 07:21:03 +0100
> 
> Do we have this kind of document?
> 
>   https://www.kernel.org/doc/html/v4.10/process/coding-style.html

See Appendix D "Tips and Conventions" in the ELisp manual.

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

[Harald Judt]

[-- Attachment #1.1: Type: text/plain, Size: 3179 bytes --]

Am 07.11.23 um 11:14 schrieb Emanuel Berg:
> Harald Judt wrote:
> 
>>>>>> Saying lets just drop these in a sec to all package
>>>>>> authors seems overreaching.
>>>>>
>>>>> Richard's question was about use of cl-lib in the Emacs
>>>>> tree, it will not (and cannot) affect
>>>>> third-party packages.
>>>>
>>>> He also mentioned about ELPA. Even if it's just the Emacs
>>>> tree it does seem overreaching unless there's
>>>> a direct benefit.
>>>
>>> On the whole, changing code that works, for that to make
>>> sense one must have a distinct improvement in mind, that is
>>> almost beyond discussion, otherwise it isn't worth the
>>> effort to do it, with everything negative and unexpected
>>> that can follow - in my experience.
>>
>> That seems to be a common but unfortunate practice nowadays,
>> that you should not touch code that is working, especially
>> rooted in corporate environments. Every improvement to the
>> code will make it easier to maintain in the long term,
>> fighting bit-rot and inconsistencies. If you touch it and it
>> fails, you simply fix it, there is nothing preventing you
>> from making changes to the code again.
> 
> Fighting bit-rot and inconsistencies is okay if those are
> small, easy and uniform to fix, and one can see a clear
> benefit of doing so (be it small in size as well).
> 
> But cl-lib is huge, any action to reduce its influence will be
> an equally huge effort - an effort that will seldom look the
> same twice - and, worse, can anyone tell for sure what the
> benefit would be again? Code that is easier to maintain?
> Why exactly, and how do we even know that?
> 
> What are we going to replace cl-1, cl-2, ..., cl-n with to get
> what kind of advantage-1, advantage-2, ..., advantage-n
> exactly? Can anyone tell, really?

My response was targeted more at the general denial to code changes, not about 
this discussion about cl-lib. Your assumption that every change needs to be 
driven by benefit seems a bit short-sighted to me. It is probably good enough 
when you want to build something fast without having to care about it much 
later. Maybe it holds when you lack time because then not wasting time is a 
priority. But if you want to build something for long-term use, it might not 
be an optimal solution. Having to depend on immediate benefits to change 
anything also loses importance when time is not that much of a priority.

If cl-lib is huge, then one should ask, why has it grown that huge? Is it just 
a badly documented one-pot of several ideas thrown together instead of someone 
doing a library using careful planning? Wouldn't it have been better then to 
replace those functions with something better? Could the situation be improved 
by revising the cl-lib documentation, or splitting up the library and 
progressively replacing it with something better?

 > No, this whole case against cl-lib doesn't add up, sorry.

Probably it is a bad idea to treat this as dragging someone to court?

Harald

-- 
`Experience is the best teacher.'

PGP Key ID: 4FFFAB21B8580ABD
Fingerprint: E073 6DD8 FF40 9CF2 0665 11D4 4FFF AB21 B858 0ABD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Emanuel Berg]

Eli Zaretskii wrote:

>>>> I looked at seq.el to try to get an idea what those
>>>> functions do. It was difficult to get this from the doc
>>>> strings, because it wasn't explicitly stated which ones
>>>> are for users and which ones are internal.
>>>
>>> Our convention nowadays is that any function/variable that
>>> has 2 dashes after the prefix, in this case
>>> seq--SOMETHING, is internal, and all the others
>>> are public.
>> 
>> Are you only allowed to use some--private-function in the
>> same file where it is defined?
>
> That's the convention, yes.

Maybe the byte-compiler should warn when using such functions
in/from other files?

>> To what extent has this convention been upheld in the
>> Emacs source?
>
> It is upheld quite closely.

Okay, great!

-- 
underground experts united
https://dataswamp.org/~incal

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

[Emanuel Berg]

Ihor Radchenko wrote:

>> Do we have this kind of document?
>>
>>   https://www.kernel.org/doc/html/v4.10/process/coding-style.html
>
> Section "D.1 Emacs Lisp Coding Conventions" in Elisp manual.

Ah, great!

(info "(elisp) Coding Conventions")

Maybe some answers to the questions are there.

-- 
underground experts united
https://dataswamp.org/~incal

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

[Emanuel Berg]

Eli Zaretskii wrote:

>> Do we have this kind of document?
>> 
>>   https://www.kernel.org/doc/html/v4.10/process/coding-style.html
>
> See Appendix D "Tips and Conventions" in the ELisp manual.

(info "(elisp) Tips")

-- 
underground experts united
https://dataswamp.org/~incal

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

[Ihor Radchenko]

Harald Judt <h.judt@gmx.at> writes:

> My response was targeted more at the general denial to code changes, not about 
> this discussion about cl-lib. Your assumption that every change needs to be 
> driven by benefit seems a bit short-sighted to me. It is probably good enough 
> when you want to build something fast without having to care about it much 
> later. Maybe it holds when you lack time because then not wasting time is a 
> priority. But if you want to build something for long-term use, it might not 
> be an optimal solution. Having to depend on immediate benefits to change 
> anything also loses importance when time is not that much of a priority.

AFAIU, Eli's position in the past was exactly as Emanuel described - we
do not change things unless there is a clear benefit of such change.

Eli, please correct me if my understanding is wrong.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Emanuel Berg <incal@dataswamp.org>, emacs-devel@gnu.org
> Date: Tue, 07 Nov 2023 12:38:49 +0000
> 
> Harald Judt <h.judt@gmx.at> writes:
> 
> > My response was targeted more at the general denial to code changes, not about 
> > this discussion about cl-lib. Your assumption that every change needs to be 
> > driven by benefit seems a bit short-sighted to me. It is probably good enough 
> > when you want to build something fast without having to care about it much 
> > later. Maybe it holds when you lack time because then not wasting time is a 
> > priority. But if you want to build something for long-term use, it might not 
> > be an optimal solution. Having to depend on immediate benefits to change 
> > anything also loses importance when time is not that much of a priority.
> 
> AFAIU, Eli's position in the past was exactly as Emanuel described - we
> do not change things unless there is a clear benefit of such change.
> 
> Eli, please correct me if my understanding is wrong.

You are not wrong, but I respectfully ask to take this discussion off
this list to emacs-tangents, since this kind of semi-philosophical
argument is not really on-topic here, and certainly doesn't belong to
the current thread.

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

[Emanuel Berg]

Harald Judt wrote:

> My response was targeted more at the general denial to code
> changes, not about this discussion about cl-lib.
> Your assumption that every change needs to be driven by
> benefit seems a bit short-sighted to me. It is probably good
> enough when you want to build something fast without having
> to care about it much later. Maybe it holds when you lack
> time because then not wasting time is a priority. But if you
> want to build something for long-term use, it might not be
> an optimal solution. Having to depend on immediate benefits
> to change anything also loses importance when time is not
> that much of a priority.

Well, now we are getting into the whole "revolution vs
evolution" discussion.

It is true that you can't expect to achieve something truly
original and great by endlessly piling up very small
incremental gains. But the great leaps are made more easily if
you have those incremental gains already.

And it is often indicative that a great leap is truly great,
if the way to it are big and small incremental gains.

> If cl-lib is huge, then one should ask, why has it grown
> that huge? Is it just a badly documented one-pot of several
> ideas thrown together instead of someone doing a library
> using careful planning? Wouldn't it have been better then to
> replace those functions with something better? Could the
> situation be improved by revising the cl-lib documentation,
> or splitting up the library and progressively replacing it
> with something better?

I think a lot of people have had a very positive experience
from it, and this is the reason for its proliferation.

But of course, incremental gains and great leaps are welcome
there as well :)

-- 
underground experts united
https://dataswamp.org/~incal

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

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Tue, 07 Nov 2023 14:50:56 +0100
> 
> Harald Judt wrote:
> 
> > My response was targeted more at the general denial to code
> > changes, not about this discussion about cl-lib.
> > Your assumption that every change needs to be driven by
> > benefit seems a bit short-sighted to me. It is probably good
> > enough when you want to build something fast without having
> > to care about it much later. Maybe it holds when you lack
> > time because then not wasting time is a priority. But if you
> > want to build something for long-term use, it might not be
> > an optimal solution. Having to depend on immediate benefits
> > to change anything also loses importance when time is not
> > that much of a priority.
> 
> Well, now we are getting into the whole "revolution vs
> evolution" discussion.

Once again, please take this discussion to emacs-tangents.  It doesn't
belong here.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > ...you are loosing me here. I'm still wondering what seq/map are good
  > for in the first place. Considering something "cleaner" is just a
  > feeling, isn't it? A feeling I don't share.

I don't concretely know, as I have not used them myself.  But I suppose
that the seq- functions do the same jobs as the cl- sequence functions.

  > > Could we replace all the cl-lib sequence function calls with seq-
  > > calls, in core and GNU ELPA code?  Seq is simpler and cleaner, so that
  > > would be an improvement.  We could keep cl-lib permanently for
  > > compatibility for external code, but it would not need to be loaded
  > > (into Emacs or your brain) very often.

  > But does that really make sense? Using either is somewhat subjective.

It is ok for a decision like this, about which of two alternative
solutions is better, to be somewhat subjective.  But it is clearly
somewhat objective too/

  > Saying lets just drop these in a sec to all package authors seems
  > overreaching.

The concept of "overreach" is not applicable to a technical decision
like this.  This isn't about respecting or not respecting anyone's
personal rights.

Surely we should not accept a moral principle that Emacs should
contain all the alternative solutions that are at least halfway
acceptable.  We must be able to limit what we include.

  > You write like lets just remove cl-lib and forget that is existed.
  > As mentioned elsewhere cl-lib isn't just sequence functions..

That is true.  This would affect the CL sequence functions, of which
it seems many or all are defined in cl-seq.el.

The overall issue concerns the CL functions in general, because of the
way they tend to be alternate versions of important facilities defined
by Emacs Lisp.  Having those sets of alternatives is a kind of bloat.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > ...you are loosing me here. I'm still wondering what seq/map are good
  > for in the first place. Considering something "cleaner" is just a
  > feeling, isn't it? A feeling I don't share.

I don't concretely know, as I have not used them myself.  But I think
that the seq- functions do roughly the same jobs as the cl- sequence
functions.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Our convention nowadays is that any function/variable that has 2
  > dashes after the prefix, in this case seq--SOMETHING, is internal, and
  > all the others are public.

Yes, and seq.el follows that.  But some of the things defined near the
top of seq.el are not functions or variables, and they don't follow
that convention.  It wasn't immediately clear to me what kind of
things they were.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Gerd Möllmann]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > ...you are loosing me here. I'm still wondering what seq/map are good
>   > for in the first place. Considering something "cleaner" is just a
>   > feeling, isn't it? A feeling I don't share.
>
> I don't concretely know, as I have not used them myself.  But I think
> that the seq- functions do roughly the same jobs as the cl- sequence
> functions.

This was about seq/map's abstraction over sequence types, using generic
functions, which AFAICT is good for nothing.

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

[Jim Porter]

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.

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

[João Távora]

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

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.

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

[Jim Porter]

On 11/9/2023 3:49 PM, Jim Porter wrote:
> I *think* Eshell could just call 'seq-map' (really, we'd want 
> 'seq-mapc', but that's another story)

Er, that's 'seq-do', actually.

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

[João Távora]

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

Have fun!  Interested to see the result.

> 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

Right, probably because in both Common Lisp and Elisp that function
is called ELT and is a very old function.  So there was no need to
add it to cl-lib.el.  keep in mind cl-lib.el comes from cl.el which
didn't have the "cl-" prefix.  So Common Lisp functions that were
exactly the same in Emacs Lisp obviously weren't in cl.el, so that's
why there's no cl-elt.

João

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

[Jim Porter]

On 11/9/2023 6:31 PM, João Távora wrote:
> Right, probably because in both Common Lisp and Elisp that function
> is called ELT and is a very old function.  So there was no need to
> add it to cl-lib.el.  keep in mind cl-lib.el comes from cl.el which
> didn't have the "cl-" prefix.  So Common Lisp functions that were
> exactly the same in Emacs Lisp obviously weren't in cl.el, so that's
> why there's no cl-elt.

I suppose that's what you get when you just try to learn the sum total 
of (Emacs) Lisp via osmosis. :) Now I know about a new function, though.

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

[Alan Mackenzie]

Hello, Jim.

On Thu, Nov 09, 2023 at 15:49:01 -0800, Jim Porter wrote:
> 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.

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.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Michael Heerdegen]

João Távora <joaotavora@gmail.com> writes:

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

We have lazy sequences in Gnu Elpa: stream.el.

Michael.

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

[João Távora]

On Fri, Nov 10, 2023 at 10:13 AM Michael Heerdegen
<michael_heerdegen@web.de> wrote:
>
> João Távora <joaotavora@gmail.com> writes:
>
> > 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.
>
> We have lazy sequences in Gnu Elpa: stream.el.

Right, and they're using seq.el in the sense I described
if I'm not mistaken.

Meaning if such object created by stream.el is somehow given
to a library in core what uses seq-* functions, that
library will do the right thing polymorphically I suppose.

João

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

[Eli Zaretskii]

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

[Michael Heerdegen]

João Távora <joaotavora@gmail.com> writes:

> > We have lazy sequences in Gnu Elpa: stream.el.
>
> Right, and they're using seq.el in the sense I described
> if I'm not mistaken.
>
> Meaning if such object created by stream.el is somehow given
> to a library in core what uses seq-* functions, that
> library will do the right thing polymorphically I suppose.

Indeed.  These streams are fully-fledged sequences in the sense of
seq.el, that was one of the basic design ideas.

Michael.