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

[João Távora]

[ Richard, with this message, I am also replying to your message in the
other thread ]

On Wed, Nov 1, 2023 at 1:48 AM Richard Stallman <rms@gnu.org> wrote:

>   >   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.
>
> That's exactly the problem.

Then why this laser-focus on cl-lib.el?  Why not criticize the use of
seq.el and map.el and pcase.el all of which "add many functions, which
have many details"?  Why are these libraries seemingly exempt from this
discussion?

The above question is mostly rhetorical, I am _not_ criticizing these
libraries or advocating restricting seq.el and map.el and pcase.el.

Reading certain parts of Emacs core has become impossible without
getting well acquainted with Stefan's Monnier pcase.el which I had to do
some 7-8 years ago.  It was an entirely alien creature when I first
saw it.  It is directly inspired by pattern matching of the ML language.

When reading a pcase,  I occasionally think to myself that it's overkill
complexity, that "in the old days" it was all much simpler.  In many
other cases I've learned to appreciate, and now it's part of my Lisp
toolbox too.

I think it's important to allow the programmers and maintainers working
on specific sections of the code a certain freedom to recommend
or select certain abstractions.  But Emacs's Lisp code base is now
very extensive and any kind of core-wide ban or rewrites of certain
patterns is counter-productive and highly contentious.  Let's be
very careful when going down that path.

On Thu, Nov 2, 2023 at 2:28 AM Richard Stallman <rms@gnu.org> wrote:
>
> 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.

Adding keyword arguments to a given function doesn't transform
Emacs Lisp into Common Lisp in any meaningful way.  Just as
translating a work by Shakespeare into Portuguese doesn't transform
Portuguese into English.  It just allows Portuguese speakers
to enjoy some very decent, maybe even essential, poetry.

Has Emacs Lisp become ML through the use of pcase.el?  Of course not.
It's become easier to write many things in Emacs Lisp, if anything.

Frequently, the argument advanced for not wanting to import feature
A or B from this other language, is "Emacs Lisp is to be kept
simple and not have this complexity".  Fair enough, programmers' craft
is foremost about managing complexity.  So very often a decision to
simplify here and now breeds enormous complexity elsewhere later.
Simplicity that proved effective and beneficial 30 years ago, in
a different context, might not really be those things today, or
30 years from now.

For example, the early decision not to have namespaces in Emacs Lisp,
taken in the name of simplicity, may have facilitated development of
Emacs features in a time where there were reasonably few packages.
But as the ecosystem grew, it created -- and still creates  -- many
challenges.

For example, one of the challenges it creates is this discussion
right here:  to be able to easily delimit what that "core" or
"standard" Emacs Lisp is -- which is what Philip Addressed.  There
is in fact no such thing.

This is _not_ necessarily advocating for namespaces/packages in Emacs
Lisp, it's just my way of pointing out that the argument of "simplicity"
is much more nuanced.  Is a keyword-argument-less 'pushnew' simpler
than 'cl-pushnew'?  Yes it is, undoubtedly.  Will the former breed
less complexity than the latter?  Very unlikely IMO.

Instead we should look at how much more complex than the hypothetical
'eq'-comparing version of 'pushnew' is `cl-pushnew` in the end.  In
the argumentless version it's exactly the same.  When a keyword
argument _is_ needed (say we need to test with #'equal or
#'my-special-comp)  doesn't that increase in complexity pay off
three-fold almost immediately?  IOW versatility of a given utility
must obviously be taken in consideration.

By the way, if it hasn't yet become apparent to you or other readers,
the keywords usually accepted to cl-sort, cl-pushnew, etc all belong
to a fairly small dictionary with consistent meaning.  For example,
the ':key' accepted by 'cl-sort' tells the thing to consider when
comparing, and the ':key' accepted by  'cl-pushnew' also tells
the thing to consider when comparing.  It is not more useful to
'cl-sort' than it is to 'cl-pushnew'.

Keyword arguments are IMHO one of the most elegant mechanisms to
promote maintainability, and generally typing less code.
Of course, there might be other possible, unique and original ways of
achieving the same of course, just as pcase.el showed me there were
other ways of doing destructuring.   But choosing any one option
just for the sake of "not being like any other language" is not the
right path to take.

João