Re: Emacs Package Management

[Stefan Monnier]

>   * remove-if / delete-if / remove-if-not / delete-if-not
>      (_without_ the CL keyword arguments)

>     [These are very handy for filtering lists of values.  The keyword
>      arguments are not very important, and keywordless core versions
>      would be compatible with keyword-supporting cl.el versions in the
>      same way that core `dolist' is compatible with cl.el `dolist']

Clearly we do not need both the *-if and the *-if-not, but I agree that
such a filtering function would come in handy at times.
OTOH the (delq nil (mapcar ...)) idiom isn't a bad replacement.

>   * mapcan
>     [Useful for mapping when there isn't a 1-1 relationship between
>     argument list elements and result list elements]

I find that (apply 'nconc (mapcar ...)) works just as well, so I don't
find it very useful.

>   * multiple-argument mapping (mapcar, mapc, etc) functions
>     [Useful and obvious generalization of existing mapping functions;
>      Gnus already contains its own implementation of a multiple-argument
>      mapcar]

I wonder what kind of impact it does/would have on performance.

In any case my main concern right now is that I do not want to introduce
any more of the "duplicate definition", like the ones of `push'
and `dolist'.

I just found out that my "clever" idea of reloading stale preloaded
files in lisp/Makefile's `compile_one' rule bumps into this problem
pretty badly: if both subr.el and vc-hooks.el are stale, then when
recompiling vc-hooks.el, we end up first reloading subr.el which
overrides the push definition previously installed by cl.el, leading to
a vc-hooks.elc that is corrupt (because it requires CL's version of
push).


        Stefan