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: Fri, 01 Oct 2010 13:36:32 -0700 Message-ID: <4CA64650.9020305@gmail.com> References: <4CA52B36.6060405@gmail.com> 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 1285965414 29147 80.91.229.12 (1 Oct 2010 20:36:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 1 Oct 2010 20:36:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 01 22:36:53 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 1P1mLb-0003s8-TB for ged-emacs-devel@m.gmane.org; Fri, 01 Oct 2010 22:36:52 +0200 Original-Received: from localhost ([127.0.0.1]:40743 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P1mLb-0007JN-8i for ged-emacs-devel@m.gmane.org; Fri, 01 Oct 2010 16:36:51 -0400 Original-Received: from [140.186.70.92] (port=43329 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P1mLQ-0007Gq-P7 for emacs-devel@gnu.org; Fri, 01 Oct 2010 16:36:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P1mLP-0002rd-Ke for emacs-devel@gnu.org; Fri, 01 Oct 2010 16:36:40 -0400 Original-Received: from mail-pw0-f41.google.com ([209.85.160.41]:39453) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P1mLN-0002r8-Sm; Fri, 01 Oct 2010 16:36:38 -0400 Original-Received: by pwj6 with SMTP id 6so2021376pwj.0 for ; Fri, 01 Oct 2010 13:36:37 -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:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=mIOONEoIXtl2Qbe9sA+Nv9LTfNBRmaxwuEdcZ0Y2J4I=; b=QXL3vR1AonRVd3jM9mGBeVvl3Ehuert0eTLnTvQYUOVV595JWE9YQPL2DEsa8QwCER GAcOuOoT0/izaW5BONt998P7cZsooyMxUVVyhgoGcX2vKBFCuWRs+7tJjvXJ+UqyQ9Pa 8MRks8YK32E/P8Md18dwDkJnKBVZtZCyJD8K8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=qwK+iE0bNIQTc9fvFTYF02rSIayS77s+Ray+GstBQNERVJZaqZpQ8lXRm7pzxo+DS4 xXJJhnIi3k1Vv34/41rjA3oV9XJEDGj8llNfBULW2xJ8x6MjYhyMLiq0XttD/zAL9k4R BUsbNaKJkZ8eOD/y0zZ5arfpvsq39aQBWfs2E= Original-Received: by 10.114.122.13 with SMTP id u13mr6954558wac.93.1285965396260; Fri, 01 Oct 2010 13:36:36 -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 q6sm2492593waj.10.2010.10.01.13.36.34 (version=SSLv3 cipher=RC4-MD5); Fri, 01 Oct 2010 13:36:35 -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:131188 Archived-At: On 10/1/2010 4:42 AM, Richard Stallman wrote: > Every Emacs release adds all sorts of functions that might impinge on > the user namespace, > > Would you please give some examples for a recent release, so it will > be clear whether you are talking about the same issue? > > Most functions in Emacs have name prefixes or suffixes which help > prevent name conflicts; those names don't pose a problem. We only > rarely add names like `remove-if' which have nothing in the name to > keep them out of the user's way, and we normally document such names > in the manual. If that practice has changed, I would like to know. Even prefixed functions and symbols can conflict with something the user has specified; the likelihood is just lower. In general, CL symbols, even without a namespace qualification, won't cause problems because cl is *already* so widely-used that anything that would conflict with it has already been fixed. Can you provide a real example of something that would break if cl.el were dumped with Emacs?