From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: moving more cl seq/mapping support into core Date: Thu, 30 Sep 2010 17:28:38 -0700 Message-ID: <4CA52B36.6060405@gmail.com> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1285892936 23330 80.91.229.12 (1 Oct 2010 00:28:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 1 Oct 2010 00:28:56 +0000 (UTC) To: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 01 02:28:55 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 1P1TUc-0002aI-EN for ged-emacs-devel@m.gmane.org; Fri, 01 Oct 2010 02:28:54 +0200 Original-Received: from localhost ([127.0.0.1]:48118 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P1TUb-00050e-RW for ged-emacs-devel@m.gmane.org; Thu, 30 Sep 2010 20:28:53 -0400 Original-Received: from [140.186.70.92] (port=38107 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P1TUV-0004zZ-TC for emacs-devel@gnu.org; Thu, 30 Sep 2010 20:28:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P1TUU-0005VE-Rx for emacs-devel@gnu.org; Thu, 30 Sep 2010 20:28:47 -0400 Original-Received: from mail-pw0-f41.google.com ([209.85.160.41]:55556) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P1TUR-0005Up-TD; Thu, 30 Sep 2010 20:28:44 -0400 Original-Received: by pwj6 with SMTP id 6so1494593pwj.0 for ; Thu, 30 Sep 2010 17:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=0lQQoDyyc/F7mxV4ck96UEbt3YaCgYwK5M+qr/dXFmY=; b=axkSfZkz7AQDwLoOy6P6bwaG3x5Fl9mSMJ/3w7s9xbmqYnqU7cXu867TO/m/Iqf1QW lPfWPTKbGFGwovqnJ6sd7jK7ZK940o+6SKtVcgjiVm1ePwAVp/TIv8dSg+Kyxt0dKNgj F9leq+uyP3Pe1S/5X7tQ0grbYnIullmMCFyjo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Dh4Wn7vE6q6BjlF0R37m1Lb06CCiNSwItSn4ZCE4CCp1DsthGLwAtpwJb5L3gFzrjL 4uEPEUNyQcopSaTuM3uy1sA97s+jOcXjPjfuTdPShw1LOIuaHsc25hggPgBbbTy+aI4E ctjiXws+Sibxdd7xh1Tmeu0mCz5xiS/Q+TXnE= Original-Received: by 10.114.66.20 with SMTP id o20mr5336288waa.163.1285892921997; Thu, 30 Sep 2010 17:28:41 -0700 (PDT) Original-Received: from [0.0.0.0] (c-67-183-23-114.hsd1.wa.comcast.net [67.183.23.114]) by mx.google.com with ESMTPS id o17sm731725wal.9.2010.09.30.17.28.39 (version=SSLv3 cipher=RC4-MD5); Thu, 30 Sep 2010 17:28:40 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:131111 Archived-At: On 9/26/2010 11:27 PM, Richard Stallman wrote: > Thanks. I think we need not to worry the user address space too much. > > That would be a change for the worse > in our standard of documentation. Every Emacs release adds all sorts of functions that might impinge on the user namespace, but it's rarely a problem in practice. CL shouldn't be held to a higher standard. In practice, many people (require 'cl) almost immediately, and a large number of packages, even those in GNU Emacs, (eval-when-compile '(require 'cl)). If cl namespace were actually a problem, we'd have heard about it long before now. In short, I really don't buy the argument that CL would cause too much namespace pollution. The benefits outweigh the tiny risk to the small number of users who work without CL loaded. CL really should be dumped along with Emacs proper. > Those are all rather heavy things by nature, so if the calling > sequence is heavy too, that's ok. > If I added a `remove-if' function I would like it not to be so heavy > to use. You can use compiler-macros (or an equivalent) to create "fast" calls when the keywords involved are known beforehand, as they almost always are. But the current CL functions are fast enough *now*, considering that they're widely used. If profiling reports that a particular call is too slow, it can always be replaced with lower-level functionality. But for the majority of code that isn't on the fast path, having CL primitives available will greatly simplify implementation.