From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: era@iki.fi Newsgroups: gmane.emacs.bugs Subject: Re: Bug in emacs Date: 16 Oct 2003 10:59:30 +0300 Organization: People Who Are Not Old Enough For Unix (Honorary Member Emeritus) Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Message-ID: <87he29ejqq.fsf@era.iki.fi> References: <004301c38cd9$2260b1a0$0100a8c0@athlon> <3F8AD296.7010803@yahoo.com> <87vfqsl64g.fsf@era.iki.fi> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1066291262 18881 80.91.224.253 (16 Oct 2003 08:01:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 16 Oct 2003 08:01:02 +0000 (UTC) Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 16 10:01:00 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AA348-00087k-00 for ; Thu, 16 Oct 2003 10:01:00 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AA33x-0005Xy-9Y for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 Oct 2003 04:00:49 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AA33F-0005Xt-Ro for bug-gnu-emacs@gnu.org; Thu, 16 Oct 2003 04:00:05 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AA32j-0005Ig-CY for bug-gnu-emacs@gnu.org; Thu, 16 Oct 2003 04:00:04 -0400 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AA32i-0005Hg-AW for bug-gnu-emacs@gnu.org; Thu, 16 Oct 2003 03:59:32 -0400 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AA32h-0000ZI-00 for ; Thu, 16 Oct 2003 09:59:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: bug-gnu-emacs@gnu.org Original-Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AA32g-0000ZA-00 for ; Thu, 16 Oct 2003 09:59:30 +0200 Original-Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AA32g-0004qU-00 for ; Thu, 16 Oct 2003 09:59:30 +0200 Original-Lines: 87 Original-X-Complaints-To: usenet@sea.gmane.org User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Bug reports for GNU Emacs, the Swiss army knife of text editors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.bugs:5987 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:5987 On 14 Oct 2003 09:05:20 +0300, era@iki.fi posted to gmane.emacs.bugs: > On Mon, 13 Oct 2003 10:28:06 -0600, Kevin Rodgers > posted to gmane.emacs.bugs: >> era@iki.fi wrote: >>> I'm not sure what the bug really is. Perhaps it would be useful to >>> get a warning when compiling / evaling something when a macro +is+ >>> in effect and the file you are compiling is not pulling it in >>> properly? Then at least you get a hint to fix it while you still >>> can, while those who do it right will not experience any adverse >>> effects. >> When the compiler comes across a (function arg ...) form, either the >> function is defined or it isn't. If it's defined, either as a function >> or a macro, all is well. If it's not defined, the compiler can't know >> whether it is a function or a macro and assumes it's a function. A >> macro can't be "in effect" if it's file was not loaded "properly". > What I'm saying is that macro expansion during compilation could > trigger a warning if the macro is not loaded properly by the code > which is being compiled. Oog, I got this backwards. (Thanks to RMS for pointing out my error in private mail.) The problem is that when a macro is +not+ defined when code is byte-compiled, the compiler assumes it's a function call; then when the compiled code is executed, and the macro +is+ defined, you get an error. The following example is hopefully representative, although I'm not sure under what circumstances the dreaded "wrong number of arguments" error is triggered -- couldn't quickly reproduce that here. ;;; trinket.el --- test case for macro error ;; ;; Steps to repeat: ;; ;; 0. Start fresh copy of Emacs ;; 1. Save this file as /tmp/trinket.el and byte-compile into /tmp/trinket.elc ;; 2. Save /tmp/macro.el (inlined below) and byte-compile into /tmp/macro.elc ;; 3. M-: (load-file "/tmp/trinket.elc") ;; 4. M-: (trinket) ;; => ERROR: Symbol's function definition is void: f (as expected) ;; 5. Visit macro.el and eval the macro definition ;; 6. M-: (trinket) ;; => ERROR: Invalid function: (macro lambda (x n) (\` (let ((m (make-list (\, n) (quote y)))) (while m (message (\, x)) (setq m (cdr m)))))) ;; 7. Restart Emacs ;; 8. M-: (load-file "/tmp/macro.elc") ;; 9. M-: (load-file "/tmp/trinket.elc") ;; 10. M-: (trinket) ;; => ERROR: Invalid function: (macro . #[(x n) "ÂÃÄÅBBDCÆÃÇ DÈBBBE‡" [n x let m make-list ((quote y)) while message ((setq m (cdr m)))] 6]) (defun trinket () (f "This is neat, isn't it?" 4) ) ;; Inlined copy of macro.el --- extract into /tmp/macro.el and byte-compile ;?;?; macro.el --- supplementary file for trinket.el ;?; ;?;(defmacro f (x n) ;?; `(let ((m (make-list ,n 'y))) ;?; (while m (message ,x) (setq m (cdr m))) )) ;?; ;?;?; macro.el ends here ;;; trinket.el ends here The main problem I guess is that the error message with the porridge of byte-compiled opcodes isn't exactly helpful, and that sometimes you have no idea which macro is causing it, and thus what defined it and when. So the upgraded wishlist suggestion would be to check whether a compiled opcode which is about to be executed is shadowed by a macro, and in that case display a warning identifying the macro in question. (As per the message I got from RMS, all macros are expanded at compilation time, so byte-compiled code should never refer to any macros, if I got this right.) Still, I think my earlier suggestion would be useful for preventing this sort of error, i.e. when performing macro expansion at byte compilation time, warn if the code in question did not manage to define the macro properly, either by including it directly, or requiring / loading / whatever a file which contains the definition. /* era */ -- The email address era the contact information Just for kicks, imagine at iki dot fi is heavily link on my home page at what it's like to get spam filtered. If you 500 pieces of spam for want to reach me, see instead. each wanted message.