From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.help Subject: Re: Is it possible for a macro to expand to nothing? Date: Sat, 28 Nov 2009 10:17:27 +1100 Organization: Rapt Technologies Message-ID: <87r5rjwoag.fsf@lion.rapttech.com.au> 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 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1259365304 8317 80.91.229.12 (27 Nov 2009 23:41:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Nov 2009 23:41:44 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Nov 28 00:41:37 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 1NEARV-0001dl-8S for geh-help-gnu-emacs@m.gmane.org; Sat, 28 Nov 2009 00:41:37 +0100 Original-Received: from localhost ([127.0.0.1]:33726 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NEARU-0004E8-TT for geh-help-gnu-emacs@m.gmane.org; Fri, 27 Nov 2009 18:41:36 -0500 Original-Path: news.stanford.edu!usenet.stanford.edu!newsfeed.news2me.com!news.astraweb.com!border2.newsrouter.astraweb.com!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) Cancel-Lock: sha1:r6RVAIu5vfGbr1Gtuh3rE5vNskc= Original-Lines: 90 Original-NNTP-Posting-Host: 788540b9.news.astraweb.com Original-X-Trace: DXC=ea=O4DAKiUeWbTVG84H7a:P3jG8S6WC]D[3m5UTdSLjFZ Original-Xref: news.stanford.edu gnu.emacs.help:175128 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:70202 Archived-At: 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. > > >> 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. > > 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? If so, then it's up to you to say how it could have been > done better, preferably submitting a patch. I have found this an interesting discussion. I'm not sure which side of the fence I fall on. Pascal/s assertion this is not good style has considerable merit. In general, I think most do expect the result from a macro to be a form that can be evaluated. On the other hand, Alan's arguments also have merit. If a macro can be useful in generating something other than a form that can be evaluated, such as a data structure and can do so in a way that is cleaner/simpler or just easier to understand than doing the same using functions, then it would make sense. His examples from the C modes seem to be a case in point. To some extent, I would suggest this is one of those situations where its ok to break the 'rules' provided you understand what the rules are and you make it explicit in your comments/documentation that this is an exception to the more common usage. In other words, Pascal is correect that generally, good style would dictate that a macro returns a form that can be evaluated. At the same time, if there is a situation where using a macro in a way that isn't totally in keeping with good style will result in code that is easier to understand/maintain, then it is reasonable to do so provided this is documented and made clear. to some extent, this follows Alan's example regarding goto. While good style suggests you should avoid goto, there are situations where using goto is the clearest and most maintainable solution, especially if avoiding its use makes you jump through a whole lot of hoops to simply avoid something that someone has said is bad style. The whole notion of what is and is not good style is all about making your code easier to understand and maintain. Style should not be viewed as a set of rules that can never be broken (or change for that matter). If anything, style guidelines are simply that, guidelines on how to write your code to make it easier to understand and maintain. When first programming, its a good idea to follow style guidelines quite religiously. However, once you understand why the guidelines are there and you become more experienced, you should understand the difference between good and bad code and know when you can break the rules. There is also a certain amount of personal taste/style that needs to be considered. I've seen code that follows all recommended style guidelines that is still almost impossible to understand and I've seen code that appears to break many style guidelines that is very clear and easy to follow. What I've found to be far more important is consistency. When working with someone elses code, you get a feel for their style and way of programming. Provided they are consistent, this isn't too bad regardless of their adherence to common style guidelines. The worst is code that sometimes adheres to guidelines and sometimes does not. My view is to try and follow the 'accepted' style guidelines for the language you are working in and document situations where you thought it necessary to do something different that is outside normal style conventions. Tim -- tcross (at) rapttech dot com dot au