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

[Po Lu <luangruo@yahoo.com>]

João Távora <joaotavora@gmail.com> writes:

> That it doesn't make maintenance any more difficult than any other
> Elisp construct, be it very old and curiously named like 'rplacd' or
> much, much newer like `seq-do` or `pcase-lambda`.
>
> My specific view on cl-lib.el is that it brings us a small part of
> the results of  non-trivial design work put in when important figures
> in the Lisp world met  regularly for many years to deliver what has
> proved to become excellent,  battle-tested, widely understood and
> impeccably documented programming abstractions.
>
> What I'm reading so far in this long discussion is that the argument
> of its detractors isn't really that cl-lib isn't good, but that
> it is superfluous and that learning it is a burden on maintainers.
> Well, it's just as superfluous as all of Elisp apart from two handfuls
> of primitives, I guess.  Or any programming language for that matter, if
> you know enough machine code.  Or any other programming abstraction I
> happen not to be familiar with.
>
> Also I seem to hear that Elisp has some kind of ideal hard-to-define
> identity or fingerprint and that it shouldn't try to become anything
> else.  But this argument is very strange given Elisp is, like any
> decent language, easy to extend.  Not to mention I struggle to see
> the technical advantage in uniqueness for uniqueness sake.  A good
> part of Elisp is about a special purpose function: editing buffers,
> and an the equally important part is about doing things with bits in
> memory, there's no reason to advocate for singularity here.
>
> I also hear Elisp shouldn't become Common Lisp, but not only is the
> use of cl-lib.el nowhere a step in that direction, but also -- somewhat
> ironically -- if Elisp _were_ Common Lisp, then that hard-to-define
> identity would be much easier to define and language extension would be
> much easier to organize into compartments to facilitate policy-making.
>
> Again, the only thing that has brought Elisp any closer to Common
> Lisp significantly, was the introduction of lexical binding some 10
> years ago.  Elisp looks a lot different now than it did in the 90's.
> Closures everywhere, higher-order functions!  Shudder!
>
> There's even talk of a continuation-passing style library, to
> be called future.el or promise.el or something.  Oh dear, what
> will be of us that we will have to evolve like any other language
> in the world!
>
> So I propose we let programmers use their judgement.  Really
> respect people who write code for no money and give the copyright
> away to the FSF.  Maybe suggest guidelines such as not introduce
> cl-loop where a dolist would do the job just as economically and
> elegantly. Don't use higher-order functions just because it looks
> cool. But maybe do suggest to use cl-position with a :key and a
> :test instead of a complex while loop with an auxiliary variable.
> Or cl-set-difference instead of nested loops.  Suggest to express
> intent, use abstractions.   Suggest to be consistent, be scrutinous,
> be "discriminate", be mindful of the style of the current area
> you are working on.

Such casuistry and non-sequiturs are the reasons I'm glad I have thus
far given this conversation a generously wide berth.  But one's
restraint has its limits, and I suppose mine have been overstepped,
since I can't keep myself from delving head-first into this madhouse.
Here goes...

> Well, it's just as superfluous as all of Elisp apart from two handfuls
> of primitives, I guess.  Or any programming language for that matter, if
> you know enough machine code.  Or any other programming abstraction I
> happen not to be familiar with.

cl-lib does certainly provide some value for money, by way of constructs
that lend themselves to many general situations, but it does not provide
this value in the lion's share of the circumstances these constructs are
used in.  Consider the blithe misapplication of CL generics throughout
the window system code:

(cl-defmethod gui-backend-set-selection (type value
                                              &context (window-system android))
  ;; First, try to turn value into a string.
  ;; Don't set anything if that did not work.
  (when-let ((string (android-encode-select-string value)))
    (cond ((eq type 'CLIPBOARD)
           (android-set-clipboard string))
          ((eq type 'PRIMARY)
           (setq android-primary-selection string))
          ((eq type 'SECONDARY)
           (setq android-secondary-selection string)))))

do we really expect window-system to be anything _but_ android, so long
as a window system has been initialized, when android-win.el is loaded?
Why was it necessary to convolute the code when g-b-s-s (and its ilk)
could as easily have been defined as an ordinary function in each of the
window system files?

For a second example, how about cl-list*?  Is there really a purpose
for this function, in light of how it can always be replaced by:

  (nconc (list a b) c)

and demands callers load cl-lib.el?  The call to this function in
desktop.el is particularly dubitable: as far as the eye can see, it is
the singular reason that file requires cl-lib, its remainder being
implemented with the cut and dry Emacs Lisp builtins that are well known
to us all.  This abject misuse of cl-lib extensions, not an unqualified
opposition to extending Emacs Lisp, is the catalyst of most misgivings
towards it.

Like begets like, even imitations of like: as the corpus of files which
load cl-lib for legitimate purposes burgeons, so does that of files
which load it for positively frivolous reasons.  Thus usage of cl-lib
should be discouraged in general, and users firmly exhorted to seek
replacements.  Even if there are situations where it is not superfluous,
their existence doesn't outweigh the proliferation of that where it is,
and ultimately it stands us in better stead to treat it as such in
general.

> That it doesn't make maintenance any more difficult than any other
> Elisp construct, be it very old and curiously named like 'rplacd' or
> much, much newer like `seq-do` or `pcase-lambda`.

pcase-lambda and seq-do (plus the boatload of seq and pcase functions)
are not "other Elisp constructs," not in my book.  seq functions are all
generic functions, and their documentation is nothing short of
inscrutable; take the example of seq-do's:

Apply FUNCTION to each element of SEQUENCE.
Presumably, FUNCTION has useful side effects.
Return SEQUENCE.

What is a useful side effect?  Does this imply FUNCTION can modify
SEQUENCE as it is being iterated through?

and each time I read the documentation for pcase, I wind up bewildered
by the needlessly laconic style it is written in.  Most of its users
don't display a persuasive need for it either, a demographic of which
frameset.el is representative: much of its work is also replicated in
the *fns.c files and frame.c, which seem to fare equally well, despite
being authored in a language that largely enjoys an absence of byzantine
constructs.

If doc strings are meant to be incomprehensible without recourse to the
Lisp reference manual, then I suggest they not be written at all.  A doc
string that alludes to and accentuates concepts such as "useful side
effects" without providing the reader with a definition or a reference
as to where he can obtain such a definition is not edifying; it leaves
an unpleasant vacuum in the reader's mind that rankles until he bows to
fate and reads the manual anyway.

rplacd and rplaca are aliases to setcar and setcdr; Emacs Lisp code
ought to use the latter, and aliases and the wholesale introduction of
functions from other languages are plainly incommensurable.

> My specific view on cl-lib.el is that it brings us a small part of
> the results of  non-trivial design work put in when important figures
> in the Lisp world met  regularly for many years to deliver what has
> proved to become excellent,  battle-tested, widely understood and
> impeccably documented programming abstractions.

It's a fair bet that Common Lisp users today number fewer than Emacs
users; of course this does not immediately reflect on the character of
features present in Common Lisp, but it is a consideration to bear in
mind.

The quality of the documentation, which for cl-lib is far from
irreproachable, cannot allay the challenge posed by learning to read and
write a language that is in plenty of respects at variance with the
language Emacs users and developers have learned.  When the latter is in
fact documented beyond reproach (save for rough spots such as the said
pcase), more than adequate for programming in Emacs, and understood by
all Emacs users, the profundity of the deliberations underlying the
design of Common Lisp and the eminence of its designers are not
justifications for its pervading Emacs code, let alone to the degree
that it has by now.

> Also I seem to hear that Elisp has some kind of ideal hard-to-define
> identity or fingerprint and that it shouldn't try to become anything
> else.  But this argument is very strange given Elisp is, like any
> decent language, easy to extend.  Not to mention I struggle to see
> the technical advantage in uniqueness for uniqueness sake.  A good
> part of Elisp is about a special purpose function: editing buffers,
> and an the equally important part is about doing things with bits in
> memory, there's no reason to advocate for singularity here.

The relative ease of extension implies that we should be more
circumspect in judging which extensions to allow--that is the basis of
much of the argumentation here, not the unsupportable notion that there
is an identity to Emacs Lisp which must be preserved at all costs.

> I also hear Elisp shouldn't become Common Lisp, but not only is the
> use of cl-lib.el nowhere a step in that direction, but also -- somewhat
> ironically -- if Elisp _were_ Common Lisp, then that hard-to-define
> identity would be much easier to define and language extension would be
> much easier to organize into compartments to facilitate policy-making.

This is self-evidently wooden language.  I expect the likes of
"compartmentalizing a program for policy-making" from suits, not from
free software developers.

> Again, the only thing that has brought Elisp any closer to Common
> Lisp significantly, was the introduction of lexical binding some 10
> years ago.  Elisp looks a lot different now than it did in the 90's.

[...]

> Closures everywhere, higher-order functions!  Shudder!

This is not ipso facto a net positive and is also beside the point.

> There's even talk of a continuation-passing style library, to
> be called future.el or promise.el or something.  Oh dear, what
> will be of us that we will have to evolve like any other language
> in the world!

I certainly hope never to see the day that becomes widespread in Emacs
code.

> So I propose we let programmers use their judgement.  Really
> respect people who write code for no money and give the copyright
> away to the FSF.  Maybe suggest guidelines such as not introduce
> cl-loop where a dolist would do the job just as economically and
> elegantly. Don't use higher-order functions just because it looks
> cool. But maybe do suggest to use cl-position with a :key and a
> :test instead of a complex while loop with an auxiliary variable.
> Or cl-set-difference instead of nested loops.  Suggest to express
> intent, use abstractions.   Suggest to be consistent, be scrutinous,
> be "discriminate", be mindful of the style of the current area
> you are working on.

Respect for volunteers is no doubt laudable, but it is very much an
position to be considered alone which everything you've presented above
does not impact and nobody takes exception to.  From it, and even
supposing for the sake of argument that everything else you've said is
incontrovertible fact, it doesn't really follow that we should not seek
to reduce the incidence of cl-lib usage in core code.  Now I can't be
certain that is the object of your militating, if you will, though
promoting cl-set-difference and cl-position as alternatives to hallowed
Emacs Lisp constructs does suggest so, but the principle argument
against these constructs is that they are alien to the small group of
individuals charged with trudging through code where people want to make
use of them.  So no contentions resting on their virtues and
distinctions rather than their prevalence among us can hold water...