Re: Lisp files that load cl-lib in problematical ways

[João Távora]

On Sat, Oct 28, 2023 at 4:20 AM Richard Stallman <rms@gnu.org> wrote:

> I think you've put your finger on it.
>
> I see nothing wrong with having an optional extension which implements
> (more or less) Common Lisp in Emacs Lisp.  That's what I thought we
> had done.
>
> However, I object to incorporating (more or less) Common Lisp an essential 
> part
> of Emacs Lisp.  And it looks like we've been drifting into that.
>
> There is no sharp line between the one and the other, and no simple
> test to determine which of those two our current situation actually
> is.  Rather, there is a spectrum that runs from "CL support is
> available but you can ignore it" to "the CL constructs are an
> essential and unavoidable part of Emacs Lisp."
>
> The specific practical questions I've asked are efforts to evaluate
> where we are now along that spectrum.  Of course, the answer to that
> isn't precise either.  But I was very surprised to learn how far
> Emacs has gone towards the latter end.

I'm going add my 2c here.  I think this whole discussion, which I haven't
followed very closely, might be slanted due to a misunderstanding.

Most, maybe all, programming languages have two different ways they can
evolve.  One is to add or modify the API offered by their standard library
by using the language itself, and another is to add or modify properties
of the fundamental mechanics of the language by changing any of the
runtime, interpreter or the compiler.

The latter can't be done using the language itself.  Now, Common Lisp
has a number of features that belong to the latter group that Emacs Lisp
doesn't have and there's no significant motion in that direction.
Examples are a namespacing system based on packages, a programmable
reader, a much more advanced condition handling system.  I'm sure
I'm forgetting some.

In fact the only way that Emacs Lisp, the core language, has approached
Common Lisp in recent years to any degree was through the addition of
lexical binding, and I think that most people here would agree that
was a very good thing.

Well, maybe native compilation also counts.  Then again, another very
good thing, I suppose.

cl-lib.el, like any other library, doesn't add -- because it really
can't -- any features of that calibre to Emacs Lisp.  It just adds
functions and macros much in the way that lots of other libraries
add functions and macros.  For example, the seq.el library is another
much later library (2014) that offers much of the same functionality of
cl-lib.el in wholly new abstractions that, say, the 2000's Emacs Lisp
coder won't be familiar with.  Another such library is pcase.
Does use of these libraries mutate Emacs Lisp programs to the point
that they are unrecognizable as Emacs Lisp programs?  Are the pcase
macros fundamentally easier to read than, say, cl-case macros?  Is
seq's sequence manipulating dictionary better than CL's?  Is
seq-some really better than cl-some? Isn't that entirely a question
of personal preference?

seq.el is preloaded and nobody seems to care (and I also don't, to
be honest).  Anyway, the point is that to hack on long-lived files
such as lisp/minibuffer.el, one can't really "ignore" the new
dictionary of seq.el anymore.

If one were to compare apples to apples one could argue that CL's
functions are _more_  accessible and quite well documented, since
both the thought put into the design of those interfaces and the use
they've seen by Lisp programmers of various breeds far exceed those
of seq.el and pcase.el.

Just my 2c,
João