Re: Why aren't `find`, `find-if`, `remove-if` part of Emacs Lisp?

[Stefan Monnier <monnier@iro.umontreal.ca>]

> That might be a description of todays implementation.  I would assume
> that you could compile away the keyword parameters relativly easily: you
> basically attach a define-compiler-macro (another CL macro) which maps
> the keyword parameters to positional parameters.

There's another problem with CL in this area: it tries to reproduce
(as faithfully as possible) the CL semantics, but in some cases, that
semantics doesn't *quite* match the Elisp semantics, so they have to
work much harder even if in 99% of the cases the difference is not
actually relevant.  E.g. in Elisp a missing optional argument is 100%
equivalent to a nil argument, whereas CL's optional argument can
distinguish the two cases, so an "&optional (x 3)" will have to be
macroexpanded into a "&rest args" and then checking the length of args
to see if the arg was provided or not.

If we were to add support for "&optional (x 3)" to Elisp, we'd either
need to change the C code that implements optional arguments, as well as
the byte-code format, so as to make the distinction between a nil and
a missing argument efficient (and get CL's semantics), or we'd just use
a simple macro-expansion approach and declare that nil is the same as
a missing argument: much simpler to implement and more in line with
usual Elisp practice.

This has happened time and time again: when Elisp incorporated a feature
present in cl.el, it typically did it in a slightly different way.
And usually the reasons are a mix of:
- because implementation simplicity is of utmost importance (given the
  lack of resources).
- because Elisp is not Common-Lisp, so the conventions, traditions, and
  expectations aren't quite the same.
- because we found a better way (e.g. compare gv-define-expander to
  define-setf-method).

Regarding macros and APIs, an important difference between Common-Lisp
and Elisp is that the expansion of a macro can only use "stable API
functions".  E.g. we can't just say "to modify this property, use (setf
<foo> ...)" and then consider the macro-expansion's result to be "an
internal detail that we can change at will" because the macroexpanded
code will be cast in stone in a foo.elc file that the user may still
want to use with Emacs-35.

So whichever setter function this `setf' method chose to use will have
to be preserved for many years.  We may elect not to advertise this
setter function, but even if we don't advertise it, we'll have to keep
supporting it to some extent.


        Stefan