From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christian Ohler Newsgroups: gmane.emacs.devel Subject: Re: moving more cl seq/mapping support into core Date: Fri, 08 Oct 2010 11:37:07 +0930 Message-ID: <4CAE7CCB.7030005@fastmail.net> References: <4CAA0FFC.5020809@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1286503650 9586 80.91.229.12 (8 Oct 2010 02:07:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 8 Oct 2010 02:07:30 +0000 (UTC) Cc: eliz@gnu.org, dan.colascione@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: MON KEY Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 08 04:07:28 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1P42Mp-0008Ih-52 for ged-emacs-devel@m.gmane.org; Fri, 08 Oct 2010 04:07:27 +0200 Original-Received: from localhost ([127.0.0.1]:35013 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P42Mo-0004QZ-LJ for ged-emacs-devel@m.gmane.org; Thu, 07 Oct 2010 22:07:26 -0400 Original-Received: from [140.186.70.92] (port=56071 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P42Mj-0004QR-Mu for emacs-devel@gnu.org; Thu, 07 Oct 2010 22:07:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P42Mi-0007QF-Df for emacs-devel@gnu.org; Thu, 07 Oct 2010 22:07:21 -0400 Original-Received: from out5.smtp.messagingengine.com ([66.111.4.29]:50138) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P42Mg-0007PR-RW; Thu, 07 Oct 2010 22:07:18 -0400 Original-Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id A6C8E52D; Thu, 7 Oct 2010 22:07:16 -0400 (EDT) Original-Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 07 Oct 2010 22:07:16 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=5ssQ6HkIV5Y08O/1gi3SrvyfoIE=; b=DEg48SPAn6OuIE4OW54fSnAfYmv2Gmqt68IL4/MArB0prsdqSpZwjOys9BVyK2f3ExWTpolP57DxCtU+34aumUU4ceBVXZ+7CCkFsd2CXXJAhTorLQhYGdgYoUcOORSz5rbXo6RrIQ99SWvmxRX7Weaga3QL0rKb0EQBNsXgWQc= X-Sasl-enc: HXuV/29DMLnGQdr9shK5U/aEFHwEYZn8Zolw+bNbuI10 1286503635 Original-Received: from [192.168.43.184] (unknown [120.16.59.111]) by mail.messagingengine.com (Postfix) with ESMTPSA id 859EE5E1FA2; Thu, 7 Oct 2010 22:07:13 -0400 (EDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:131460 Archived-At: 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.