[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: moving more cl seq/mapping support into core

From: Christian Ohler
Subject: Re: moving more cl seq/mapping support into core
Date: Fri, 08 Oct 2010 11:37:07 +0930

 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?


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]