From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dave Love Newsgroups: gmane.emacs.devel Subject: Re: cc-vars.el Date: 19 Nov 2002 16:55:47 +0000 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200211180057.JAA24537@etlken.m17n.org> <5bbs4m8qz9.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 1037725068 23581 80.91.224.249 (19 Nov 2002 16:57:48 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 19 Nov 2002 16:57:48 +0000 (UTC) Cc: 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 18EBgh-00066z-00 for ; Tue, 19 Nov 2002 17:57:23 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18EBjT-0002gM-00 for ; Tue, 19 Nov 2002 18:00:16 +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 18EBff-00006R-00; Tue, 19 Nov 2002 11:56:19 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18EBfN-00083a-00 for emacs-devel@gnu.org; Tue, 19 Nov 2002 11:56:01 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18EBfJ-00081m-00 for emacs-devel@gnu.org; Tue, 19 Nov 2002 11:56:00 -0500 Original-Received: from albion.dl.ac.uk ([148.79.80.39]) by monty-python.gnu.org with esmtp (Exim 4.10) id 18EBfG-00080W-00; Tue, 19 Nov 2002 11:55:54 -0500 Original-Received: from fx by albion.dl.ac.uk with local (Exim 3.35 #1 (Debian)) id 18EBf9-0008Fr-00; Tue, 19 Nov 2002 16:55:47 +0000 Original-To: Martin Stjernholm Original-Lines: 65 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 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:9547 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9547 Martin Stjernholm writes: > True, but it's more valid within different versions of the same > branch, e.g. between Emacs 20 and 21, You definitely can't rely on Emacs 21 byte code running in Emacs 20. > and even more so between minor versions. There's no guarantee of that either, particularly if macro expansions change to use new features. > I had at one point a simple macro system that tested all > this at compile time and made completely tailored byte code, and I got > a complaint from a user then. I don't understand that. I wouldn't worry about details of the compiled code. > The only way to avoid compiler warnings cleanly (in some sense) is to > do the tests with macros at compile time, I don't think that's true. Definitely not if compilation is done in batch, file-by-file so that stuff in `eval-when-compile' doesn't affect other compilations. > Don't you rather mean code like this? > > (if (fboundp 'fred) > (fred ...)) Yes, sorry. > It'd be cool if the compiler did enough flow analysis to cope with > that, but it might be hard to get it to work well, and if it doesn't > work well then I'd prefer to have the possibility to control the > warnings explicitly with some pragma-like system. It doesn't do data-flow analysis, and doesn't need to in order to do this sort of thing usefully. It was a simple change to the function that compiles `if'. > An interesting angle is if something like the following can be used > (although I'd consider this too a workaround rather than a solution): > > (if (boundp 'fido) > (symbol-value 'fido)) > (if (fboundp 'fred) > (funcall 'fred ...)) > > Someone with insight in the inner workings of the compiler can perhaps > advice on how effectively it manages to optimize such things. (equal (byte-compile (lambda () (if (fboundp 'fred) (funcall 'fred)))) (byte-compile (lambda () (if (fboundp 'fred) (fred))))) => t I think CL used such a trick, but it's not (now) effective. > Anyway, this is besides the point regarding cc-bytecomp, since that > one is necessary to keep it working and compiling without warnings on > both Emacs and XEmacs. I don't see what the real difference is between cc-mode and Gnus in this respect, but then I'm not maintaining cc-mode.