Re: Why aren't there functions such as filter, take-while, etc. "by default"?

[David Kastrup <dak@gnu.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Why does it have to be so hard to write Emacs Lisp without requiring cl?
>>> Why aren't there functions such as filter (the equivalent of
>>> remove-if-not in cl-seq.el), take-while, reduce etc. "native" in
>>> Emacs?
>> They make for no-surprise efficient programs primarily when the language
>> has lexical closures.
>
> I do not understand this.  What do you mean to say, and why is dynamic
> scoping relevant (i.e. why wouldn't the same argument apply to mapcar,
> mapconcat, etc...).

It does apply to the latter functions equally well.  However, those tend
to be usable with primitive functions without dynamic consequences
somewhat more often.

The more complex filtering functions of Common Lisp are very much
employed as an alternate programming style for iteration.  If there is
no conceivable way to transform them into byte code (or whatever) with a
similar efficiency and predictability as the equivalent iteration code,
they seem like a bad idea.

When learning Elisp, I have been negatively surprised by the bad
performance of using map* functions as opposed to straight iteration.

I should really like to see a version of Elisp where one-shot lambda
functions with outer references
a) need not be written
  (let ((outer ...)) ... `(lambda (x) (... ',outer ...
b) byte compile into the same or equally efficient byte code as their
   open-coded iteration equivalents

It is ok if the debugger can use debugging info/signatures for
approximating dynamical access for the user to the anonymous stack slots
of lexical variables, but normal operation should not be affected.

Since Lisp, after all, is supposed to be a functional language, I'd like
to see Emacs Lisp not penalize functional programming styles.  Currently
it does, and so I don't think general-purpose iteration constructs
encouraging lambda predicates are a good idea for now.

It would appear that both the lexbind branch as well as an all-out guile
strategy could provide paths forward.  The latter would seem to have the
advantage that we can get rid of the whole byte compilation issue in the
Emacs codebase (which would likely get more rather than less complex
with lexbind).  _And_ give guile a large kick forward in improvement
incentives.  Likely more than the boost that the Emacs project gives
Bazaar, and with more immediate benefits.

-- 
David Kastrup