GNU bug report logs - #57397
29.0.50; cl-letf blindly macroexpands places

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 57397 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: bug#57397: cl-letf blindly macroexpands places
Date: Sat, 03 Sep 2022 22:55:53 -0400

>> No the problem shows up in the `gv-letplace` that follows immediately,
>> so by the time we get to the `symbolp` test it's too late.
>> But I suspect that the better fix is to skip the macroexpand call here
>> and to change `gv-get` so as to do a `macroexpand-1` call even if its
>> arg is a `symbolp`.
>
> Ok, you have obviously more insight here, so can you maybe...take over
> this part?

Pushed to `master`.

> Ok - does this look correct?

Looks good, yes.

> BTW, I had trouble understanding the paragraph about the compiler-macro
> declare specs in (info "(elisp) Declare Form"), in particular the calling
> convention:
>
> | [...] When encountering a call to the function, of the form ‘(FUNCTION
> | ARGS...)’, the macro expander will call EXPANDER with that form as
> | well as with ARGS...
>
> not only because of the colons, but also because it's...wrong?  EXPANDER
> is called with one argument, and the other formal arguments are
> available (bound) to the corresponding argument forms, right?

There are two cases: one is when EXPANDER is of the form (lambda ...)
and the other is when it's not (in which case it'll be a symbol naming
a function defined elsewhere).

When you write

    (defun my-foo (arg1 &optional arg2)
      (declare (compiler-macro (lambda (whole) ..blabla..)))
      ..toto..)

it is macro expanded to something more or less equivalent to:

    (defun my-foo (arg1 arg2)
      (declare (compiler-macro my-foo--expander))
      ..toto..)
    (defun my-foo--expander (whole arg1 &optional arg2)
      ..blabla..)

> Could you then maybe rephrase a bit [I don't want to, my English is not
> good enough.  I'm able to do it but it always takes much too long to
> find a good wording.]

I can see the source of your confusion, but I'm not sure how to write it
better, without making it much more verbose (and risk making it yet
more confusing).

Would something like the patch below help?


        Stefan


diff --git a/doc/lispref/functions.texi b/doc/lispref/functions.texi
index 983dfe2ec59..8e34fdf3640 100644
--- a/doc/lispref/functions.texi
+++ b/doc/lispref/functions.texi
@@ -2476,11 +2476,11 @@ Declare Form
 expander will call @var{expander} with that form as well as with
 @var{args}@dots{}, and @var{expander} can either return a new expression to use
 instead of the function call, or it can return just the form unchanged,
-to indicate that the function call should be left alone.  @var{expander} can
-be a symbol, or it can be a form @code{(lambda (@var{arg}) @var{body})} in
-which case @var{arg} will hold the original function call expression, and the
-(unevaluated) arguments to the function can be accessed using the function's
-formal arguments.
+to indicate that the function call should be left alone.
+
+To avoid syntactic redundancy, when @var{expander} is of the form
+@code{(lambda (@var{arg}) @var{body})} the function's formal arguments
+are automatically added to the lambda's list of arguments.
 
 @item (gv-expander @var{expander})
 Declare @var{expander} to be the function to handle calls to the macro (or

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.