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

[Drew Adams]

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

FWIW, to me, all of what you say there is welcome news.

When incorporating whatever you describe as incorporating
from cl-* into Elisp (using `equal' as default), I hope
you mean giving it some other name than the CL name it
has (ignoring the `cl-' prefix or not).  I think that's
what you have in mind, when you say this:

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

IOW, to me it would be fine to get such a function for
Elisp, but _not_ to have it keep the CL name but with
altered semantics (e.g. `equal' default, not `eql').

I've long argued that if we have a Common Lisp emulation
library then it should be a reasonable emulation, and
not gratuitously deviate from CL behavior/semantics.

It would not be good to keep the CL name for a function
but change its behavior from defaulting with `eql' to
defaulting with `equal'.  Better to give it a different
name.  At _least_ drop the `cl-' prefix, but better to
avoid any confusion by giving it an altogether different
name.