unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: pjb@informatimago.com (Pascal J. Bourguignon)
To: help-gnu-emacs@gnu.org
Subject: Re: Is it possible for a macro to expand to nothing?
Date: Thu, 26 Nov 2009 12:11:10 +0100	[thread overview]
Message-ID: <87ocmp7d81.fsf@galatea.local> (raw)
In-Reply-To: hel8kr$c6u$1@colin2.muc.de

Alan Mackenzie <acm@muc.de> writes:

> Jeff Clough <jeff@chaosphere.com> wrote:
>> From: Alan Mackenzie <acm@muc.de>
>> Date: Tue, 24 Nov 2009 16:39:20 +0000 (UTC)
>
>>>> It comes directly from the definition of defmacro,
>
>>>>    defmacro is a special form in `src/eval.c'.
>>>>    (defmacro name arglist [docstring] [decl] body...)
>
>>>>    Define name as a macro.  The actual definition looks like
>>>>     (macro lambda arglist [docstring] [decl] body...).
>>>>    When the macro is called, as in (name ARGS...), the function
>>>>    (lambda arglist body...) is applied to the list ARGS... as it
>>>>    appears in the expression, and the result should be a form to be
>>>>    evaluated instead of the original.
>
>>> Oh, come on!  That last sentence is a tutorial, motivating one,
>>> expressed in the slightly loose, colloquial language of the hacker.
>>> "a form to be evaluated" is here shorthand for something like "some
>>> sort of atom or list structure which fits into the slot where the
>>> invocation is housed"
>
>> This is incorrect.  The term "form" has a very specific definition in
>> Lisp.  It is a sexp that can be evaluated.  While I'm new to Lisp, I
>> have been knee deep in books and documents for the last couple of weeks
>> and everything (including the GNU Emacs Lisp Manual) presents macros as
>> a way to generate *forms*, not just sexps.
>
> You've missed my point.  The guy who wrote that definition of macro was,
> in using the word "form", being somewhat, er, informal.  It was just
> easier and more concise to say "form" than "form or (sometimes) other
> appropriate list structure".

He was informal only as much as the "emacs lisp reference manual"
doesn't contain a glossary entry for "form".  The reason why is that
because at the time emacs was invented, it was a well known technical
term established for 30 years meaning "an executable sexp".

Only a few years later did Common Lisp get formalized with a
normalizing glossary, where you can find the formal definition for
form which I cited.  Notice that it is justified to retrofit most
definitions of the Common Lisp glossary to the older lisps, since
Common Lisp is after all not much more than the GCD of the lisps that
existed at the time.



>> If you have a macro that expands to (1 2 3), it's not going to break
>> the world, but that macro isn't doing what every hacker is going to
>> expect.  I'd call that a style problem.
>
> Just like somebody occasionally using a goto in C.  Pascal was unable to
> identify any specific problem a non-form macro expansion causes.

I cited several times the reason why it's bad: because the macro form
cannot be used stand alone without signaling an error.  Jeff says the
same.  You could ask on comp.lang.lisp where I'd bet you'd get even
more gurus answering.  (Real lisp gurus intervene sometimes on cll).


>> If, for some reason, you absolutely have to use a macro to generate
>> something like that above, at least have it expand to (list 1 2 3),
>> that way the macro can still be evaluated and no one gets shafted.
>
> And waste run time evaluating that list every time the defun runs?

That depends on what you're doing.  But indeed, by advice is to use a
_function_ to return (1 2 3) and avoid rebuilding the list several
time.


>> You get the behavior you want and the macro is still expanding to a
>> valid form.
>
> Nobody has yet given a valid reason why I should care about a macro
> expansion being a "valid form" when the invoker is not going to evaluate
> it.  cc-langs.el is chock full of such "invalid forms", yet they make the
> maintenance of 7 complicated language modes tractable.

It is a _style_ reason.  A question of good taste.   The same reason
why you don't poop in your living room.   It would be bad style.


To make an analogy, there is a room where you can defecate, there's a
room where you watch TV.  Technically, there's no reason why you
shouldn't be able to defecate in your living room, but for style
reasons (and because you don't have to paper over it later), it's
better if you keep defecating in your water closed room.


-- 
__Pascal Bourguignon__


  reply	other threads:[~2009-11-26 11:11 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-23 14:56 Is it possible for a macro to expand to nothing? Alan Mackenzie
2009-11-23 16:03 ` Drew Adams
     [not found] ` <mailman.11344.1258992201.2239.help-gnu-emacs@gnu.org>
2009-11-23 16:31   ` Alan Mackenzie
2009-11-23 17:29     ` Drew Adams
2009-11-23 18:33     ` Pascal J. Bourguignon
2009-11-23 18:51       ` Drew Adams
     [not found]       ` <mailman.11354.1259004470.2239.help-gnu-emacs@gnu.org>
2009-11-23 20:08         ` Pascal J. Bourguignon
2009-11-23 20:24           ` Alan Mackenzie
2009-11-23 22:09           ` Drew Adams
     [not found]           ` <mailman.11367.1259014174.2239.help-gnu-emacs@gnu.org>
2009-11-23 23:55             ` Pascal J. Bourguignon
2009-11-24  0:55               ` Alan Mackenzie
2009-11-24  9:42                 ` Pascal J. Bourguignon
2009-11-24 10:45                   ` Alan Mackenzie
2009-11-24 11:14                     ` Pascal J. Bourguignon
2009-11-24 16:39                       ` Alan Mackenzie
2009-11-24 19:17                         ` Pascal J. Bourguignon
2009-11-25 14:13                         ` Jeff Clough
     [not found]                         ` <mailman.11467.1259158369.2239.help-gnu-emacs@gnu.org>
2009-11-26  6:53                           ` Alan Mackenzie
2009-11-26 11:11                             ` Pascal J. Bourguignon [this message]
2009-11-26 11:52                               ` Lennart Borgman
     [not found]                               ` <mailman.11564.1259236392.2239.help-gnu-emacs@gnu.org>
2009-11-26 12:16                                 ` Pascal J. Bourguignon
2009-11-26 12:43                                   ` Lennart Borgman
2009-11-27  8:32                         ` Kevin Rodgers
     [not found]                         ` <mailman.11626.1259310779.2239.help-gnu-emacs@gnu.org>
2009-11-27 13:15                           ` Alan Mackenzie
2009-11-27 13:52                             ` Pascal J. Bourguignon
2009-11-27 16:57                               ` Alan Mackenzie
2009-11-27 17:09                                 ` Pascal J. Bourguignon
2009-11-27 17:19                               ` Helmut Eller
2009-11-27 17:45                                 ` Pascal J. Bourguignon
2009-11-27 23:17                             ` Tim X
2009-11-28  0:06                               ` Pascal J. Bourguignon
2009-11-28  8:29                                 ` Alan Mackenzie
2009-11-28 10:25                                   ` Pascal J. Bourguignon
2009-11-28 12:57                                     ` Thierry Volpiatto
     [not found]                                     ` <mailman.11699.1259413441.2239.help-gnu-emacs@gnu.org>
2009-11-29  0:54                                       ` Pascal J. Bourguignon
2009-11-24 11:56                     ` Pascal J. Bourguignon
     [not found]     ` <mailman.11352.1258997403.2239.help-gnu-emacs@gnu.org>
2009-11-23 18:42       ` Pascal J. Bourguignon
2009-11-23 20:12         ` Drew Adams
     [not found]         ` <mailman.11356.1259007263.2239.help-gnu-emacs@gnu.org>
2009-11-23 20:21           ` Pascal J. Bourguignon
2009-11-23 22:09             ` Drew Adams
     [not found]             ` <mailman.11368.1259014177.2239.help-gnu-emacs@gnu.org>
2009-11-24  0:03               ` Pascal J. Bourguignon
2009-11-23 20:09       ` Alan Mackenzie
2009-11-23 16:49 ` Jeff Clough

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ocmp7d81.fsf@galatea.local \
    --to=pjb@informatimago.com \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).