From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.help Subject: Re: Is it possible for a macro to expand to nothing? Date: Tue, 24 Nov 2009 16:39:20 +0000 (UTC) Organization: muc.de e.V. Message-ID: References: <87vdh1ccra.fsf@galatea.local> <87my2dc8d7.fsf@galatea.local> <873a44dcf2.fsf@galatea.local> <87pr78b6n9.fsf@galatea.local> <87ljhwb2dx.fsf@galatea.local> NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1259080856 17274 80.91.229.12 (24 Nov 2009 16:40:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Nov 2009 16:40:56 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Nov 24 17:40:49 2009 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NCyRc-0000gP-FR for geh-help-gnu-emacs@m.gmane.org; Tue, 24 Nov 2009 17:40:49 +0100 Original-Received: from localhost ([127.0.0.1]:39475 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCyRb-0003ct-Sh for geh-help-gnu-emacs@m.gmane.org; Tue, 24 Nov 2009 11:40:47 -0500 Original-Path: news.stanford.edu!usenet.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!newsgate.news.xs4all.nl!news2.euro.net!newsfeed.freenet.de!news.space.net!news.muc.de!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 148 Original-NNTP-Posting-Host: marvin.muc.de Original-X-Trace: colin2.muc.de 1259080760 25149 2001:608:1000::2 (24 Nov 2009 16:39:20 GMT) Original-X-Complaints-To: news-admin@muc.de Original-NNTP-Posting-Date: Tue, 24 Nov 2009 16:39:20 +0000 (UTC) User-Agent: tin/1.6.2-20030910 ("Pabbay") (UNIX) (FreeBSD/4.11-RELEASE (i386)) Original-Xref: news.stanford.edu gnu.emacs.help:175018 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:70089 Archived-At: Pascal J. Bourguignon wrote: > Alan Mackenzie writes: >> Pascal J. Bourguignon wrote: >>> Alan Mackenzie writes: >>>> Pascal J. Bourguignon wrote: >>>>> "Drew Adams" writes: > Valid lisp code is the kind of lisp code that eval can process and > return the result without signaling an error (it can signal errors > internally, if they are caught). OK. It is quite valid for macros to generate portions of valid code, or data upon which code can operate. > My claim is that it is not a good style to write a macro that produces > non valid lisp code, ..... So you have said, time after time, without producing any coherent reasoning to back it up. The following .... > .... because lisp macros are designed to produce code that will be > evaluated by the lisp eval, , is a mere assertion which I am convinced is false. It seems to be on a par with saying "gotos are harmful". Well, yes they are, sort of, but on other occasions are useful indeed. The same surely applies to lisp macros which generate things not evalable. > If you want to transform code for other processors, or random data, use > functions. Functions are not as usable as macros, or are more awkward and hence error prone, or require excessive use of `eval-while-compile' and lots of juggling with , ,@ ` and the like. Your notion of the correct use of macros seems to be a religious idea rather than one fully thought through. You justify it with circular reasoning. Whilst using a macro to generate an evalable form may be the most usual thing, there is no reason not to use it to produce other list structure. >>> But cc-langs.el only defines four macros and they all generate >>> perfectly good lisp code. >> Any macro, once debugged, generates "perfectly good" lisp code. I >> don't understand where this notion of "perfectly good" comes from. > It means valid lisp code, see definition above. Circular reasoning. >>> Unfortunately, most of emacs lisp code is bad code. Functions one >>> kilometer long, chained with one or more others one kilometer long. >>> Copy-and-pasted chunks instead of abstracting it away. Etc. >> I can't disagree with that, sadly. However I think Emacs's code base >> is better than a typical 25 yo application still under development (if >> there is such a beast). > Yes, the fact that it still runs, is still useful, and can still be > maintained despite these bad parts is proof of it, that it's better > than typical 25 yo or even a lot of much younger programs. >>> The general contract of a macro is that it returns valid forms. >> Sorry, Pascal, you're just restating the same thing again, not >> answering my question. Why should I accept this "general contract of >> a macro"? I haven't signed it. ;-) Is there some respected Lisp guru >> who says this? > It comes directly from the definition of defmacro, > defmacro is a special form in `src/eval.c'. > (defmacro name arglist [docstring] [decl] body...) > Define name as a macro. > The actual definition looks like > (macro lambda arglist [docstring] [decl] body...). > When the macro is called, as in (name ARGS...), > the function (lambda arglist body...) is applied to > the list ARGS... as it appears in the expression, > and the result should be a form to be evaluated instead of the original. Oh, come on! That last sentence is a tutorial, motivating one, expressed in the slightly loose, colloquial language of the hacker. "a form to be evaluated" is here shorthand for something like "some sort of atom or list structure which fits into the slot where the invocation is housed" >> What would this guru say about the macro which generates a >> font-lock-defaults structure? > If this structure cannot be passed to eval without signaling an error, > then I would say that it is bad style to use a macro to generate such > data. OK. So people who might have benefitted from a clever macro now have to do things more laboriously and more erroneously. Another example you would call bad would be `define-minor-mode' which, in addition to creating a top level command also creates a keymap, a syntax table, and so on. Would you propose eliminating `define-minor-mode' from Emacs? >>> (defmacro ifdef (expr &rest body) >>> (and (eval expr) `(progn ,@body))) >> That version of ifdef is ugly because it contains an obtrusive >> `progn'. > In a way here, progn is the dual of list. > When you want to generate a list of data, you use list: > `(list ,expr1 ,expr2 ... ,exprN) > When you want to generate a list of code, you use progn: > `(progn ,form1 ,form2 ... ,formN) > It is not obtrusive in any way, it only shows that we are generating > code, not mere data. It makes the generated code more difficult to read, because it has no function, unless it has some specific function. >> It seems this `progn' is there purely to satisfy >> the (as yet unsubstantiated) injunction to return only "perfectly good" >> lisp forms. > Not 'purely'. You could optimize it out when unnecessary with: > (defun progn-encapsulate (forms) > (if (= 1 (length forms)) > (first forms) > (list* 'progn forms))) , or I could just have the macro return (form1 form2 .... formn), ready to be spliced into the caller. -- Alan Mackenzie (Nuremberg, Germany).