Re: moving more cl seq/mapping support into core

[Christian Ohler <ohler+emacs@fastmail.net>]

  On 6/10/10 9:59, MON KEY wrote:
> Does Ohler believe that his CL duplicates are better for their
> non-conformance and breaking with both the semantics of both the CL
> features and the Common Lisp features? Maybe he finds his duplicates
> achieve a desirable performance gain. Or, maybe he just doesn't feel it
> worth the trouble to rewrite _all_ of cl*.el.

Because a run-time dependency on cl.el would make it hard for ERT to 
become part of Emacs and triggers distracting warnings, I reimplemented 
the subset of CL that ERT requires.  I don't think this subset is better 
than cl.el, and I haven't checked which implementation is faster.

> If Ohler implemented his CL feature duplications as a kludge would he
> have simply done a (require 'cl) and been done with it were it not for
> the CL runtime ban?

Yes.

> And if so, would ERT be better/more correct by so doing?

Better?  Probably, since I could have spent my time on other features, 
and the definitions in cl.el may well be faster than my reimplementations.

More correct?  I'm not sure.  You are examining the behavior of 
`ert--remove-if-not' etc. for Common Lisp compliance; but there is no 
reason why it would have to be, since these functions are just private 
utilities in ERT.  They only provide the subset of CL functionality that 
ERT requires.  They either document that they only work on lists, or 
signal an error on sequence types that they don't support.

The check for dotted lists that you are looking for is guaranteed in 
Common Lisp only in what Common Lisp calls "safe code".  In safe code, 
Common Lisp also guarantees this check for `loop' and `member'; but 
`loop' and `member' in Emacs Lisp don't have this check.  So, ERT's 
CL-like utility functions behave like unsafe code in this regard, just 
like other Emacs Lisp functions.

If you have a concrete reason to believe that these functions lead to 
bugs in ERT, please let me know.

Reimplementing these CL utility functions (in 
http://github.com/ohler/ert/commit/cdc3dfad4779cb9421a6711f6ef7be522ca8e5b0 
) was actually only part of the work I had to do to avoid a run-time 
dependency on CL.  I also had to implement a special-purpose replacement 
for `typep' in 
http://github.com/ohler/ert/commit/bde37b42d0187356cfd747d5ec245b30690c2fcf 
, and the trickiest part was making ERT's call to `macroexpand' work 
regardless of whether cl.el is loaded, see 
http://github.com/ohler/ert/commit/f481a5c2b38a8ccd06b9ddd9c7243409fb583ea2 
: If cl.el is loaded, ERT needs to pass two arguments to `macroexpand', 
only one otherwise.  The solution is simple, but figuring out that this 
problem exists took me a while.

Christian.