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 10:45:32 +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> NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1259062921 18822 80.91.229.12 (24 Nov 2009 11:42:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Nov 2009 11:42:01 +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 12:41:50 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 1NCtmF-0003w1-12 for geh-help-gnu-emacs@m.gmane.org; Tue, 24 Nov 2009 12:41:47 +0100 Original-Received: from localhost ([127.0.0.1]:59511 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCtmD-0006ZT-Uv for geh-help-gnu-emacs@m.gmane.org; Tue, 24 Nov 2009 06:41:45 -0500 Original-Path: news.stanford.edu!usenet.stanford.edu!news.glorb.com!news2.glorb.com!peer1.news.newnet.co.uk!newsfeed.freenet.de!news.tu-darmstadt.de!news.muc.de!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 93 Original-NNTP-Posting-Host: marvin.muc.de Original-X-Trace: colin2.muc.de 1259059532 41297 2001:608:1000::2 (24 Nov 2009 10:45:32 GMT) Original-X-Complaints-To: news-admin@muc.de Original-NNTP-Posting-Date: Tue, 24 Nov 2009 10:45:32 +0000 (UTC) User-Agent: tin/1.6.2-20030910 ("Pabbay") (UNIX) (FreeBSD/4.11-RELEASE (i386)) Original-Xref: news.stanford.edu gnu.emacs.help:175011 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:70082 Archived-At: Pascal J. Bourguignon wrote: > Alan Mackenzie writes: >> Pascal J. Bourguignon wrote: >>> "Drew Adams" writes: >>> This is the problem! Macros shouldn't return a _list_, they should >>> return a _form_. If you write a macro that returns a list, or you >>> use it so that it returns a list, that is not a valid form, then it >>> is not good style, even if you catch up. >> Is that right? I think you should be required to justify this >> assertion of "good style". If that "good style" really is good style, >> then the whole of cc-langs.el (which uses intense macro magic to >> generate data structures with both compile-time and run-time >> behaviour) is attrocious style. > If that was the case, yes, I would think so. Macros are designed to > generate code, not other data. I'm no lisp guru, but I must disagree strongly with this. What is code, what is data? Surely they are essentiallty the same, particularly in lisp. You would hold that a macro which generates a font-lock-defaults structure (so as to reduce the tedium of doing it by hand) is an abuse of the macro idea, would you? > If you are generating general data, then using functions will be easier > and clearer. If it's possible. But if this were the case, using functions to generate "code" would be easier and clearer, too. > 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. >> Fact is, though, it allows a simple tabular writing of constants which >> vary between C, C++, java, .... Kudos to Martin Stjernholm, who wrote >> it. > 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). > Now of course, I had a peek at code that had bugs or missing features > in the first place. Perhaps the good quality emacs lisp code I hadn't > a peek at because it worked well enough so I didn't need to. Perhaps. >>> Because it is a better style. It avoids abusing the ifdef macro. >> Where does this notion of "abuse" come from? What is its rationale? >> (This is a genuine question.) > 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? What would this guru say about the macro which generates a font-lock-defaults structure? > In all fairness, ifdef does return valid forms, when provided valid > forms as argument. > (defmacro ifdef (expr &rest body) > (and (eval expr) `(progn ,@body))) That version of ifdef is ugly because it contains an obtrusive `progn'. The version I used doesn't. There is no guarantee that a lisp compiler, particularly the Emacs lisp byte compiler, is going to optimise away this unnecessary artifact. It seems this `progn' is there purely to satisfy the (as yet unsubstantiated) injunction to return only "perfectly good" lisp forms. > The fact that such a macro call embedded in another form building form > that processes it properly doesn't mean that it is not bad style: it > has to do something special to the result of ifdef to make it work. > If you extract that ifdef call to run it at the repl, it just cannot > work. Yes. -- Alan Mackenzie (Nuremberg, Germany).