[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is it possible for a macro to expand to nothing?

From: Pascal J. Bourguignon
Subject: Re: Is it possible for a macro to expand to nothing?
Date: Tue, 24 Nov 2009 20:17:37 +0100
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.3 (darwin)

Alan Mackenzie <address@hidden> writes:

> Pascal J. Bourguignon <address@hidden> wrote:
>> Alan Mackenzie <address@hidden> 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__

reply via email to

[Prev in Thread] Current Thread [Next in Thread]