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

[Eli Zaretskii <eliz@gnu.org>]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: João Távora <joaotavora@gmail.com>,
>  adam@alphapapa.net, emacs-devel@gnu.org,  stefankangas@gmail.com
> Date: Thu, 02 Nov 2023 08:55:54 +0000
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> > It might be ok to add some keyword arguments to `sort', which are more
> > unusual and complex to use, but not to simple constructs like
> > `pushnew'.  This is Emacs Lisp, not Common Lisp.
> 
> What does that last sentence mean?

AFAIU, it means that Emacs Lisp traditionally doesn't use keyword
arguments, except as relatively rare exceptions.

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

> to me the main aspects and attractions of Emacs Lisp (in contrast to
> CL and Scheme) have been:
> 
> 1. Not standardised; it is possible to extend the language without
>    having to worry about how many implementations will follow along

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

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.

> Emacs Lisp can learn from interesting ideas that other
> languages provide, adapt and add them, making them available to
> everyone.

It certainly can.  The question is: should it?  Since we are not
driven by any standard, it is completely up to us to make those
decisions, and we should IMO make them judiciously and carefully,
taking the downsides into consideration.  In particular, I hope people
agree that making a language too large and complex is not a good
thing in the long run.

> If a form expresses something that people frequently want to
> do, but either have to elaborate using (unless (memq ...) (push ...)),
> then we are making Emacs more useful and expressive by providing the
> functionality OOTB.  And isn't that the real point of Emacs Lisp?

AFAIU, what Richard says is that if some form is frequently used, we
should indeed consider adding a primitive or an API for it, but that
primitive or API doesn't have to look like CL.  Cf the pushnew
argument.