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

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

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

It is used rather prominently in `define-minor-mode' or
`define-derived-mode', or do you specifically mean keyword arguments to
functions?

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

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

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.

> 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?  But yes, I
am not advocating for senselessly adding whatever seems remotely
interesting, of course.

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

Right, I agree with everything here.  The functionality, not the style
is of interest.