From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ilya Shlyakhter Newsgroups: gmane.emacs.devel Subject: Re: CL package suggestion Date: Mon, 9 Apr 2012 00:54:01 -0400 Message-ID: References: <27y5qciwgd.fsf@fencepost.gnu.org> <9lty10iwdr.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf3036388b7599ed04bd37cbed X-Trace: dough.gmane.org 1333947256 26040 80.91.229.3 (9 Apr 2012 04:54:16 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 9 Apr 2012 04:54:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 09 06:54:15 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SH6cH-0007YI-0p for ged-emacs-devel@m.gmane.org; Mon, 09 Apr 2012 06:54:13 +0200 Original-Received: from localhost ([::1]:43234 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SH6cG-0005jC-Gm for ged-emacs-devel@m.gmane.org; Mon, 09 Apr 2012 00:54:12 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42303) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SH6cD-0005iK-6F for emacs-devel@gnu.org; Mon, 09 Apr 2012 00:54:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SH6cB-0000lp-7u for emacs-devel@gnu.org; Mon, 09 Apr 2012 00:54:08 -0400 Original-Received: from mail-yw0-f41.google.com ([209.85.213.41]:46654) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SH6c7-0000kJ-J5; Mon, 09 Apr 2012 00:54:03 -0400 Original-Received: by yhr47 with SMTP id 47so2013673yhr.0 for ; Sun, 08 Apr 2012 21:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=D/8tghxiWN3vhrqN9Na8x8lIg/Qk98pa3gYS1fXFX9s=; b=YcSJsPf2+yoEnnuPcvLboaiy2eFzx50sk1Xu+qNp5HIvt+6cPMbOrO7eLivpsB0Gvl fGNOYhjPoYP2YeScMrVudj+NXsBuqDaT+tBOnX5I/7Al/NkjhLoymQIdshC2BoxPgECx pM5Osa/k1RBz6xvXcqz82IC11bmNQZbi6tpzrCJhxrTIqyNAsKAJm2urO++jPTBArGOt wsBHHaWLymJiqgJDbDbk9dJz8FmFHYfAYocioErLLqriu0RPTQdwg6ANXKI6TQNdUMBK YI5MkyCAmu9Ay3H52JpLm5+FuRJ6X/406KvfZtJwu5rWD+5wnDcTRTuH/RvrO6JCpxxm J+OA== Original-Received: by 10.236.125.168 with SMTP id z28mr4755458yhh.120.1333947241175; Sun, 08 Apr 2012 21:54:01 -0700 (PDT) Original-Received: by 10.147.168.13 with HTTP; Sun, 8 Apr 2012 21:54:01 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: lNUqrHKbKE-hxVHjUqS-eM5zyqc X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.213.41 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:149492 Archived-At: --20cf3036388b7599ed04bd37cbed Content-Type: text/plain; charset=ISO-8859-1 So, about the cl package: If remove-if is renamed cl-remove-if and then 'remove-if defaliased to 'cl-remove-if, is it now ok to (require 'cl) at runtime? Won't the alias now conflict with whatever definition of remove-if the user had? And if you don't (require 'cl) at runtime, then you can't call cl-remove-if at runtime, since it might not be available. One could move cl-remove-if etc into a separate module called cl-funcs, so if you want to call cl-remove-if at runtime you (require 'cl-funcs). This would somewhat break up the logical structure of the cl package, since things will get grouped by whether they're functions or macros rather than by topic. Suggestions? On Wed, Apr 4, 2012 at 9:06 AM, Stefan Monnier wrote: > > Agree about cl- being better than ecl- . > > Btw, if remove-if becomes defalias'ed to cl-remove-if, aren't the two > calls > > indistinguishable to the byte compiler? > > The name is different, so the compiler can definitely tell the difference. > > > If they are, and calling cl-remove wouldn't trigger a warning, > > wouldn't remove-if calls also become warning-less? > > Not necessarily, no. > > > Stefan > --20cf3036388b7599ed04bd37cbed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So, about the cl package:

If remove-if is renamed cl-rem= ove-if and then 'remove-if defaliased to 'cl-remove-if,
i= s it now ok to (require 'cl) at runtime? =A0Won't the alias now con= flict with whatever
definition of remove-if the user had? =A0=A0
And if you don&= #39;t (require 'cl) at runtime, then you can't call cl-remove-if at= runtime,
since it might not be available.

One could move cl-remove-if etc into a separate module called cl-funcs,
so if you want to call cl-remove-if at runtime you (require 'cl-= funcs).
This would somewhat break up the logical structure of the= cl package,
since things will get grouped by whether they're functions or macr= os rather than by topic.

Suggestions?
On Wed, Apr 4, 2012 at 9:06 AM, Stefan Monnier= <monnier@= iro.umontreal.ca> wrote:
> Agree about cl- being= better than ecl- .
> Btw, if remove-if becomes defalias'ed to cl-remove-if, aren't = the two calls
> indistinguishable to the byte compiler?

The name is different, so the compiler can definitely tell the differ= ence.

> If they are, and calling cl-remove wouldn't trigger a warning,
> wouldn't remove-if calls also become warning-less?

Not necessarily, no.


=A0 =A0 =A0 =A0Stefan

--20cf3036388b7599ed04bd37cbed--