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:39:09 -0700 Message-ID: <4CA646ED.4070101@gmail.com> References: <4CA52B36.6060405@gmail.com> <87vd5m1u1u.fsf@catnip.gol.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1285965566 29777 80.91.229.12 (1 Oct 2010 20:39:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 1 Oct 2010 20:39:26 +0000 (UTC) To: emacs-devel@gnu.org, miles@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 01 22:39:24 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 1P1mO1-0004OM-Ci for ged-emacs-devel@m.gmane.org; Fri, 01 Oct 2010 22:39:21 +0200 Original-Received: from localhost ([127.0.0.1]:36493 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P1mO0-0000iN-S9 for ged-emacs-devel@m.gmane.org; Fri, 01 Oct 2010 16:39:20 -0400 Original-Received: from [140.186.70.92] (port=44283 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P1mNv-0000ge-GS for emacs-devel@gnu.org; Fri, 01 Oct 2010 16:39:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P1mNu-0003VM-Dp for emacs-devel@gnu.org; Fri, 01 Oct 2010 16:39:15 -0400 Original-Received: from mail-px0-f169.google.com ([209.85.212.169]:61624) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P1mNu-0003VA-6k; Fri, 01 Oct 2010 16:39:14 -0400 Original-Received: by pxi5 with SMTP id 5so2001486pxi.0 for ; Fri, 01 Oct 2010 13:39:13 -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=n9aCO9FlpfuN0yWILwnV9YfqTfFmMpeIHyc0KU0EXZM=; b=Oh1KmsEq7iQLpKP5bWShGLGxqALBjrSD3uw1up7RPRyxTmxU8rKJ9tE+xBmfOuVL/Q 52jBHgrz2cZ5JfGJfsNEXewGTNJkJAO8ZdWqEbekZCt1kRaRjViGjCpZvhbQinpIxjY7 wjR1UtOBBrwbdWi25Gp2hDwBzDJRwSNma17AA= 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=ZsfY9fqozdK1P1cW/J/FvInpRBl43opCwovJydRKVKI34oU9eWDdR0sYzXuBaXEd/4 c4mSHbcV3oSkNz01HRsplS8JUVFx8Ifqm1jXptStmCtMSjyV1k7dGmlSsCDWemwZcky8 666kXmXMYADx++r68OQuxsZg7zYgxBsjELgkQ= Original-Received: by 10.114.123.9 with SMTP id v9mr6973042wac.130.1285965553134; Fri, 01 Oct 2010 13:39:13 -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 s5sm2501855wak.0.2010.10.01.13.39.11 (version=SSLv3 cipher=RC4-MD5); Fri, 01 Oct 2010 13:39:12 -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: <87vd5m1u1u.fsf@catnip.gol.com> 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:131189 Archived-At: On 9/30/2010 8:16 PM, Miles Bader wrote: > Daniel Colascione writes: >> CL really should be dumped along with Emacs proper. > > cl.el is a combination of good useful things that and horrible ugly > things (this isn't a comment on the CL language, btw -- many of the > problems with cl.el are issue with its implementation and consistency > with elisp). Can you point to a few examples? Parts of cl are ugly (the common use of make-symbol instead of gensym, for example, makes macroexpansions difficult to read). But those don't affect functionality or interaction with other packages. The other issue is the set of extension functions --- defun*, defmacro* and so on. If your point is that the functionality offered by these functions should instead of folded into the regular elisp versions, then that's a good thing, but news to me. > Of course, there's a solution which would probably make everybody > happy: adopt the good things only, and fix some of the problems with > the horrible ugly things so that they can be adopted. But people > advocating cl.el seem to usually stop short of putting any effort into > doing that... What are the good things/ What are the "horrible ugly thing"? What criteria can you use to distinguish them?