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

[Eli Zaretskii]

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

> >> 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"?

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

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