Re: Lisp files that load cl-lib in problematical ways

[Richard Stallman <rms@gnu.org>]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

You seem to be judging features in terms of how much fundamental
change it makes in Emacs Lisp.  What you say about these changes, at
that level, seems to be valid, but it's a different issue, thus a
change of subject.

The problem of widespread use of cl-lib is that it adds a lot of
details to what one needs to know to work on Elisp programs.

  > In fact the only way that Emacs Lisp, the core language, has approached
  > Common Lisp in recent years to any degree was through the addition of
  > lexical binding,

Lexical binding, as a language feature, adds little complexity of
details to Emacs Lisp.  Once you kow what it is, the only added detail
is how to enable it for a given source file, and that is very simple.

  > Well, maybe native compilation also counts.

That too adds little complexity, expecially if you don't turn it on
when you build Emacs.  I haven't had to learn anything to understand
Elisp programs because of the existence of native compilation.

  > cl-lib.el, like any other library, doesn't add -- because it really
  > can't -- any features of that calibre to Emacs Lisp.  It just adds
  > functions and macros much in the way that lots of other libraries
  > add functions and macros.

This is what maks cl-lib such a pain: it adds many functions, which
have many details.  When lots of Emacs Lisp programs use cl-lib, that
means all those details become more things everyone working on Emacs
Lisp programs needs to know.

In other words, you're judging various changes by how deeply they
change the Emacs Lisp language, but the problem I'm concerned with is
about how many superficial changes they make.

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

  > If one were to compare apples to apples one could argue that CL's
  > functions are _more_  accessible and quite well documented,

The documentation that counts, for Emacs Lisp, is documentation that
is suitable to integrate into Emacs.  It has to be technically
suitable (written in Texinfo) and legally suitable (under a free
license compatile with the GFDL).  If it isn't in Texinfo, integrating
it into Emacs would be a substantial job, If it isn't
license-compatible, we would have to rewrite it starting from zero.

If it isn't free, we cannot refer to it as documentation at all.

Is there clear and well-written documentation for cl-lib which fits
those criteria?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)