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: Sun, 8 Apr 2012 21:41:51 -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=20cf302d49c83dac0d04bd351cca X-Trace: dough.gmane.org 1333935726 30067 80.91.229.3 (9 Apr 2012 01:42:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 9 Apr 2012 01:42:06 +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 03:42:03 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 1SH3cJ-0005Ad-3y for ged-emacs-devel@m.gmane.org; Mon, 09 Apr 2012 03:42:03 +0200 Original-Received: from localhost ([::1]:57691 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SH3cI-0007xf-HZ for ged-emacs-devel@m.gmane.org; Sun, 08 Apr 2012 21:42:02 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43612) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SH3cE-0007xa-OW for emacs-devel@gnu.org; Sun, 08 Apr 2012 21:42:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SH3cD-0002mx-4i for emacs-devel@gnu.org; Sun, 08 Apr 2012 21:41:58 -0400 Original-Received: from mail-gy0-f169.google.com ([209.85.160.169]:62731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SH3c9-0002md-Uq; Sun, 08 Apr 2012 21:41:54 -0400 Original-Received: by ghrr18 with SMTP id r18so1990100ghr.0 for ; Sun, 08 Apr 2012 18:41:51 -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=6W8rScdkIP/jf7umqWGO57DbMCNM6+QTn+B29UI/5Bo=; b=Z54KEroBFu/qqKjLmZlAGYmwyj26qwsey+tkxO85MXHwHZmBlVlKrAB8AsC+hMCw9q ZHIAa59XQvOgkcJ4YLFOrouxxQsBYfh3quF8lPl+K9dhWentXyCv3qQd3Bm4Q7+OCKf4 5bVn+DsHSxXrhVL9t6rtHumwdcaPXSja5TYgI4qT/1JUPEMwZc5M/hf1GtvpEUsXcJRt bO1wsv0XibIuAMvRkBnrlX5fah5TZ+0Qzs9ucXJmz3IdpnGm03YjOE8x8ZhPodGG519A 7l+qurDYA1w1aVw6JQ7QsLZQzQAi0yKH+su4xZ68veevB7+XgRLC00Q7124S8BnL4uVg UKHg== Original-Received: by 10.236.154.2 with SMTP id g2mr4442010yhk.103.1333935711562; Sun, 08 Apr 2012 18:41:51 -0700 (PDT) Original-Received: by 10.147.168.13 with HTTP; Sun, 8 Apr 2012 18:41:51 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: kM1250EvpPZhPSP1To6HjiNuZyk X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.160.169 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:149486 Archived-At: --20cf302d49c83dac0d04bd351cca Content-Type: text/plain; charset=ISO-8859-1 I'm sorry, the example I gave is fine -- that code of course is executed at compile-time only. On Sun, Apr 8, 2012 at 9:39 PM, Ilya Shlyakhter wrote: > Right now, the cl package itself seems to violate the rule against calling > its functions at runtime. > E.g. > > (define-compiler-macro assoc* (&whole form a list &rest keys) > ;; ... > (if (floatp-safe (cl-const-expr-val a)) > ;; ... > > floatp-safe is a function in package cl, and the compiled code will call > it at runtime. > Am I missing something? > > 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 >> > > --20cf302d49c83dac0d04bd351cca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm sorry, the example I gave is fine -- that code of course is execute= d at compile-time only.

On Sun, Apr 8, 20= 12 at 9:39 PM, Ilya Shlyakhter <ilya_shl@alum.mit.edu> wrote:
Right now, the cl package itself seems to vi= olate the rule against calling its functions at runtime.
E.g.=A0
<= div>
(define-compiler-macro assoc* (&whole form a list &= amp;rest keys)
;; ...
=A0 =A0 =A0 =A0 =A0 =A0(if (floatp-safe (cl-const-expr-val a))
=A0;; ...

floatp-safe is a function in package = cl, and the compiled code will call it at runtime.
Am I missing s= omething?

On Wed, Apr 4, 2012 at 9:06 = AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:<= br>
> 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


--20cf302d49c83dac0d04bd351cca--