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

[Philip Kaludercic <philipk@posteo.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: rms@gnu.org,  joaotavora@gmail.com,  adam@alphapapa.net,
>>   emacs-devel@gnu.org,  stefankangas@gmail.com
>> Date: Thu, 02 Nov 2023 21:26:00 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > AFAIU, it means that Emacs Lisp traditionally doesn't use keyword
>> > arguments, except as relatively rare exceptions.
>> 
>> It is used rather prominently in `define-minor-mode' or
>> `define-derived-mode', or do you specifically mean keyword arguments to
>> functions?
>
> I did mention exceptions, didn't I?
>
> And define-derived-mode supports keyword arguments only since Emacs
> 22; the original implementation didn't.

Ok, I interpreted this as in "few usages", not in "few definitions".

>> >> what constitutes "Emacs Lisp"?  It would
>> >> seem peculiar if it were to be defined by the arbitrary decisions of the
>> >> past, constrained by the contingent circumstances of the time.
>> >
>> > Those "arbitrary decisions" are what got us to where we are now, 40
>> > years later.  So some respect for those "arbitrary decisions" is due,
>> > I think.
>> 
>> No disrespect meant, but I am not sure we are thinking of the same
>> things.  An "arbitrary decision" usually doesn't matter much, like
>> calling a function rplacd or setcdr.  If a decision got us to where we
>> are now, I would say it wasn't that arbitrary, but a good one?
>
> Exactly my point.  So what did you mean by "It would seem peculiar if
> [what constitutes Emacs Lisp] were to be defined by the arbitrary
> decisions of the past"?

That "setcar" is supposed to be more Elisp-ish than "rplacd", or things
like that. 

>> > IMNSHO, extending Emacs Lisp as the language is not the main goal of
>> > Emacs development.  Emacs Lisp is not a programming language on its
>> > own, it is a language for implementing and extending features and
>> > extensions in Emacs.  Thus, the main goal of Emacs development is to
>> > develop applications and application-level features, and provide more
>> > opportunities for extending the core where that is considered useful.
>> > What we have in Emacs Lisp is IMO ample for that purpose.  Moreover,
>> > most participants in Emacs development are not experts in programming
>> > languages, their expertise is elsewhere (which is definitely a Good
>> > Thing).
>> 
>> Of course not extending it for its own sake, but I would assume that
>> making it easier for users to write practical and useful code should be
>> something that is valued.
>
> We should consider such additions carefully, weighing their advantages
> against the disadvantages: introducing "alien" syntax, making the
> language larger, etc.

What I had in mind were extensions like the recent `with-restriction'.
Defining something like this came to my mine on more than one occasion
when combining `save-restriction' and `narrow-to-region' in exactly the
same pattern as I had done many times before, because it seems natural
to have it combined in a single form.  I don't think this is necessarily
alien, perhaps even natural in the long term.

>> > Objectively, adding new syntax and semantics to Emacs Lisp does make
>> > the source code harder to read and maintain, because it makes the
>> > language larger and requires familiarization with those new language
>> > features, which more often than not look and feel completely different
>> > from the "traditional" Emacs Lisp.  So even if we conclude that these
>> > additions are worthwhile, we should not pretend they come without a
>> > price, and IMO we should think carefully whether their use is
>> > justified before we use them in each and every case.
>> 
>> Could you explain what you mean by "traditional" Emacs Lisp?
>
> Basically, the language as it is, without macros whose syntax is
> different from Emacs Lisp.  For example, cl-loop has syntax that to my
> eyes is starkly not Emacs Lisp, because it uses many keyword-like
> parts that look like they were lifted from Fortran.

Then again (cl-)loop is a peculiar example; even among CL programmers
there are many that dislike using it on the same grounds.  As a macro,
it doesn't really even attempt to blend into the surrounding language,
but uses special keywords and syntax parsing, that has both its
advantages and disadvantages, but it is still used if only because CL
doesn't have a simple `while' macro.

This is a much more stark example than pushnew.  I could imagine that
pushnew could be implemented without a keyword argument, if we accepted
three arguments (newelt place compare-fn).

But there are a plenty of definitions in cl-lib that in some form or
another I think would be nice to have in Elisp proper as well: list*,
flet, defmacro/defgeneric, defstruct would be some examples that come to
mind.  This is not only my personal perspective, but the feeling I get
from reviewing Elisp packages that include cl-lib for only two or three
definitions.