From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: cc-vars.el Date: Wed, 20 Nov 2002 08:58:54 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: <200211201358.gAKDwsG21304@rum.cs.yale.edu> References: <200211180057.JAA24537@etlken.m17n.org> <5bbs4m8qz9.fsf@lister.roxen.com> <5bwun97ecw.fsf@lister.roxen.com> <20021119165749.GA27657@gnu.org> <5b65utkyqt.fsf@lister.roxen.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1037800930 4246 80.91.224.249 (20 Nov 2002 14:02:10 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 20 Nov 2002 14:02:10 +0000 (UTC) Cc: Martin Stjernholm , Dave Love , Kenichi Handa , rms@gnu.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18EVQc-00016H-00 for ; Wed, 20 Nov 2002 15:02:06 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18EVTp-0005rE-00 for ; Wed, 20 Nov 2002 15:05:25 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18EVOy-0002bJ-00; Wed, 20 Nov 2002 09:00:24 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18EVNk-0008Ph-00 for emacs-devel@gnu.org; Wed, 20 Nov 2002 08:59:08 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18EVNf-0008DG-00 for emacs-devel@gnu.org; Wed, 20 Nov 2002 08:59:06 -0500 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.10) id 18EVNb-00083N-00; Wed, 20 Nov 2002 08:58:59 -0500 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id gAKDwsG21304; Wed, 20 Nov 2002 08:58:54 -0500 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Miles Bader Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:9563 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9563 > Martin Stjernholm writes: > > > /.../ A few extra fboundp checks at load-time are so utterly > > > inconsequential that it's hardly worth worrying about the possibility that > > > they might be generated in some cases. > > > > What makes you think they are restricted to load time code? > > The idioms I'm thinking of are: > > (if (fboundp 'foo) > (foo bar) > (foo-work-around bar)) > > which will work for `when' too, due to macroexpansion: > > (when (fboundp 'foo) > ...do stuff... > (foo bar) > ...do more stuff...) > > I'd probably make it work for `and' too, so you could do: > > (and (fboundp 'foo) (foo bar)) > > What case do you have in mind where these aren't sufficient? > Can you give examples? Obviously your example are in run-time code, not in load-time code, so you seem to agree with him that the fboundp checks will not just occur at load-time. > > What would be the problem of adding a macro in the bytecomp > > environment to control the warning aspect only? That has to be > > simpler than recognizing the if-form. It's not like it's an either-or > > issue between two irreconcilable solutions. > No, but let's not add both unless it's actually necessary. There's already a macro to turn off warnings for variables: (defvar foo). I suggested to do the same for (defun bar), but IIRC Richard vetoed it because he thinks pragmas to turn off some warnings are just wrong. The fact is that people do want them and end up cobbling up hackish ones (as we've seen with cc-bytecomp; I myself used something like (eval-when-compile (autoload 'foo "bar")), so we might as well provide clean ones. This way we could even add an "ignore pragmas" flag for people who like to get all the warnings. As for whether or not pragmas will ever be made unnecessary, my opinion is that it seems highly unlikely that we'll ever get the byte-compiler to understand all the cases where a function call is safe. But I also completely agree that we should try to make sure that pragmas as needed as rarely as possible, so I wholeheartedly support Dave's suggestion which will at least reduce the amount of useless warnings. Stefan