From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: pjb@informatimago.com (Pascal J. Bourguignon) Newsgroups: gmane.emacs.help Subject: Re: Is it possible for a macro to expand to nothing? Date: Tue, 24 Nov 2009 20:17:37 +0100 Organization: Informatimago Message-ID: <873a43bulq.fsf@galatea.local> 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 1259091927 23526 80.91.229.12 (24 Nov 2009 19:45:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Nov 2009 19:45:27 +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 20:45:20 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 1ND1KC-0004kF-6q for geh-help-gnu-emacs@m.gmane.org; Tue, 24 Nov 2009 20:45:20 +0100 Original-Received: from localhost ([127.0.0.1]:49199 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ND1KB-0006eU-LH for geh-help-gnu-emacs@m.gmane.org; Tue, 24 Nov 2009 14:45:19 -0500 Original-Path: news.stanford.edu!usenet.stanford.edu!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 73 Original-X-Trace: individual.net ivgiVbHVOWZ6QG5tBG5D3wDsCNZPPUoT9NkUnc+VmNsz3dHOir Cancel-Lock: sha1:OTAzOGZiZDk4M2RmOTQ2MjgyMTE0OTExY2NhMTYyMGE2MjU3NjRjNw== sha1:6Y0ptxbowkpB/QbpIkM03PXab1U= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en X-Disabled: X-No-Archive: no User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.3 (darwin) Original-Xref: news.stanford.edu gnu.emacs.help:175023 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:70094 Archived-At: Alan Mackenzie writes: > Pascal J. Bourguignon wrote: >> Alan Mackenzie writes: >>> 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. That's where you're wrong, using functions to generate data is simplier and less erroneous than using macros to do the same. > 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? define-minor-mode generates a valid lisp form. You can execute a define-minor-mode macro call without getting an error. >>>> (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. Why do you use variable names from a natural language dictionnary? Names have no function, you should use gensyms... >>> 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. No, because such a macro you couldn't use it at the REPL or in any other function. -- __Pascal Bourguignon__