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: Fri, 27 Nov 2009 16:57:28 +0000 (UTC) Organization: muc.de e.V. Message-ID: References: <87my2dc8d7.fsf@galatea.local> <873a44dcf2.fsf@galatea.local> <87pr78b6n9.fsf@galatea.local> <87ljhwb2dx.fsf@galatea.local> <873a406poe.fsf@galatea.local> NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1259343654 12019 80.91.229.12 (27 Nov 2009 17:40:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Nov 2009 17:40:54 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Nov 27 18:40:47 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 1NE4oJ-0001IO-09 for geh-help-gnu-emacs@m.gmane.org; Fri, 27 Nov 2009 18:40:47 +0100 Original-Received: from localhost ([127.0.0.1]:54248 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NE4oI-00053U-Jr for geh-help-gnu-emacs@m.gmane.org; Fri, 27 Nov 2009 12:40:46 -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.tu-darmstadt.de!news.muc.de!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 109 Original-NNTP-Posting-Host: marvin.muc.de Original-X-Trace: colin2.muc.de 1259341048 11249 2001:608:1000::2 (27 Nov 2009 16:57:28 GMT) Original-X-Complaints-To: news-admin@muc.de Original-NNTP-Posting-Date: Fri, 27 Nov 2009 16:57:28 +0000 (UTC) User-Agent: tin/1.6.2-20030910 ("Pabbay") (UNIX) (FreeBSD/4.11-RELEASE (i386)) Original-Xref: news.stanford.edu gnu.emacs.help:175118 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:70191 Archived-At: Pascal J. Bourguignon wrote: > Alan Mackenzie writes: >> Kevin Rodgers wrote: >>> Alan Mackenzie wrote: >>>> 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. >>> Except that such macros can only be executed in a particular context >>> i.e. they depend on something that cannot be expressed via their >>> argument list. >> Yes, many lisp structures can only be "executed" in particular contexts, >> `,@' for example, yet nobody slags them off for that. > This is different. Why can't you see it? I do see it. I'm glad we both do - there are things which _are_ different. > ,@ cannot be put outside of a ` context, never ever. Yes. It is a thing which can only be "executed" in a particular context. We live with this. > When you define a macro (defmacro m ...) then (m ...) can be put in any > form context, always. No. When _you_ define a macro that might well be the case, but with me there are no guarantees. I might want a macro to generate an arm of a cond form, for example. Unlikely, but possible. > Oops! Not when you write a macro that returns not a form. You've made > an exception, and therefore a lot of complexity for the reader of your > code, and a lot of time lost for the debugger of your code. Right. We now get down to weighing up the difficulties a non-form macro may cause to its readers compared with the simplicity in the manner of expression which it would allow. > Now instead of being able to use a macro at any place a form is > acceptable, we have to go read the source of the macro, and understand > whether it returns a form or data, and if it's the later, we have to > understand how to wrap it in some boilerplate, which was by the way > why macros where invented for in the first place, to avoid > boilerplate!!! How silly! No, not silly - it all depends. In the example which sparked off this intelligent discussion, avoiding non-conformity required inserting an artificial `progn'. It's a matter of judgement which is the more difficult to read and understand. >>> At best that is poor style, and at worst it is poor engineering. >> That is so supercilious - you haven't even given an example of this >> phenomenom, discussing why it is poor style or poor engineering. There's >> just this vague insinuation that you know better. > Yes, it seems that we have to spell it in all details. Yes, indeed. Or at least, in some considerable detail. >> I will give an example, namely `c-lang-defconst' from cc-defs.el. Are >> you going to assert that it is poor style, or even poor engineering, >> simply because it generates an internal data structure rather than an >> excutable form? > You are plain wrong. c-lang-defconst, as any other macro, generates > only executable lisp code: Yes, I was wrong. Sorry about that. I'm beginning to see what you're getting at. > (c-lang-defconst test t nil c "abc") > --> test > (macroexpand '(c-lang-defconst test t nil c "abc")) > --> (progn (c-define-lang-constant (quote test) (quote (((c-mode) . "abc") (t))) (quote (\83)))) I still don't see the _reason_ for macros always to return forms. I think you're saying that anything else is so unusual that it would create problems for somebody reading or debugging it. Do you have an example of somewhere where a macro expanding to a non-form has lead to difficulty? I can't imagine anybody having difficulty understanding code like this: (cond (try-incoming-call event) ; expands to a full cond arm (try-incoming-data-call event) (try-battery-low-notification event) (try-keyboard-press event) .... ) , where all these event handler macros are defined centrally just once (and the comment is actually present in the source). I'll quite happily use a goto in C code if it makes the code easier to read and understand, though I've only done this 3 or 4 times in my entire career. Similarly, I'd use a non-form macro if this were better. Usually it wouldn't be. -- Alan Mackenzie (Nuremberg, Germany).