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

[Richard Stallman]

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

  > There's a difference between (1) adding &key to
  > Elisp generally and (2) letting more functions
  > take advantage of :key and :test, in particular.

That is a valid distinction.

I would be happy to see a keyword argument facility provided for
function definitions in Emacs Lisp.  There are occasions where it is
good for a function to accept keyword arguments -- especially those
functions that need to accept lots of arguments.

What I object to are the keyword arguments used in Common Lisp to call
simple, everyday functions.  For instance, the sequence functions.
(For this reason, I prefer the seq- functions to the Common Lisp
sequence functions.)

But we can split that issue by making another distinction, between
(2a) sequence functions that _accept_ the Common Lisp sequence
function keywords, such as :key and :test, and
(2b) frequently needing to pass those arguments.

(2a) does not make most code any more clumsy.  It affects only the
_definitions_ of these sequence functions.  What makes code ugly is
(2b).

Logically, (2a) does not force (2b), but the two are directly related.
The designers of Common Lisp saw (2a) as providing an opportunity to
"simplify" by eliminating the predefined functions to compare using
`equal' and to compare using `eq'.  By default they use `eql',
which says "a pox on both `memq' and `member'."

In practice, that makes the Common Lisp functions inconvenient to use.

I would not be unhappy if Emacs Lisp functions started to support :key
and ;test where they make sense, provided they did this in an Emacs
Lisp way: default comparison is `equal'.

(We should take care to implement it without a slowdown in the case
where the keyword args are not specified.)

This means that `member' would accept ;test, but it would still
compare using `equal' by default (if :test was nil or not specified).
And there would still be `memq' to compare with `eq'.

When I say "new functions", that includes any Common Lisp functions
that are currently available in cl-seq.el with a cl- prefix but NOT
treated as part of Emacs Lisp.  To treat them as part of Emacs Lisp,
we should make them compatible, we should (1) make them default to
Emacs Lisp tradition and (2) accompany them with a corresponding q
function, if comparing using `eq' is useful for that function.

We would also rename the function, as part of the bargain, to avoid an
incompatibility.

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