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

[Christoph Wedler <christoph.wedler@sap.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Barry Margolin <barmar@alum.mit.edu> writes:

>> Basically, RMS thinks CL is too bloated. From 
>> http://www.gnu.org/gnu/rms-lisp.html:
>
>> Obviously, machines are bigger now, and we don't do it that way any 
>> more. We put in 'caar' and 'cadr' and so on, and we might put in another 
>> looping construct one of these days. We're willing to extend it some 
>> now, but we don't want to extend it to the level of common Lisp.

Actually, nowadays the "bloated argument" can be reversed: because many
ELisp libraries basically reimplement specialized versions of many CL
functions, the complete ELisp code (and even subsets of average-used
size) is more bloated that CL + libs that make use of CL.

>> I implemented Common Lisp once on the Lisp machine, and I'm not all that 
>> happy with it. One thing I don't like terribly much is keyword arguments 
>> (8). They don't seem quite Lispy to me;

Hm, there are good reasons why :KEYWORD is specially highlighted by
font-lock - it is also used in custom, face/display specs, ...  It might
be un-early-Lispy...  OK, loop is un-Lispy (and bloated).

>> (8) I don't mind if a very complex and heavyweight function takes keyword
>> arguments.  What bothers me is making simple basic functions such as
>> "member" use them.

To be honest, I like keyword arguments a lot - whenever the meaning of a
parameter is not clear from its position, it should be a keyword
parameter.  If you look at existing functions, the sequence of the
parameter can quite often only be explained by the history of that
function.

What is wrong with the keyword parameters :test, :test-not and :key of
cl-member (should be `member' ;-)) - which position do you want to give
them - or do you want to invent extra function names for them?

> Agreed.  They also work OK for macros since those are not supposed to be
> executed at run-time.  Keyword arguments are particularly problematic in
> Elisp where the language implementations are all fairly simplistic with
> very limited optimizations.

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.