* Re: master 2c2dfbb: ; Fix some typos in doc strings and manuals
2021-04-24 17:45 ` master 2c2dfbb: ; Fix some typos in doc strings and manuals Stefan Monnier
@ 2021-04-24 19:34 ` Štěpán Němec
2021-04-24 21:58 ` Stefan Monnier
0 siblings, 1 reply; 4+ messages in thread
From: Štěpán Němec @ 2021-04-24 19:34 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 674 bytes --]
On Sat, 24 Apr 2021 13:45:40 -0400
Stefan Monnier wrote:
>> --- a/doc/lispref/macros.texi
>> +++ b/doc/lispref/macros.texi
>> @@ -486,7 +486,7 @@ variable with the same name as one of the macro arguments. Inside the
>> macro body, the macro argument binding is the most local binding of this
>> variable, so any references inside the form being evaluated do refer to
>> it. Here is an example:
>> -
>> +@c FIXME with lexical-binding t this example no longer applies
>
> Thanks, I tried to address this problem.
Thank you!
I found parts of the new text a bit hard to read and/or understand, and
wonder if something like the following could be an improvement. WDYT?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-doc-lispref-macros.texi-Eval-During-Expansion-Copy-e.patch --]
[-- Type: text/x-patch, Size: 2627 bytes --]
From 9d4cde283ce5deb22bc36dfee50eb20490b6ec54 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C5=A0t=C4=9Bp=C3=A1n=20N=C4=9Bmec?= <stepnem@gmail.com>
Date: Sat, 24 Apr 2021 21:19:48 +0200
Subject: [PATCH] * doc/lispref/macros.texi (Eval During Expansion): Copy edit.
---
doc/lispref/macros.texi | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/doc/lispref/macros.texi b/doc/lispref/macros.texi
index 7c090aebc866..b8df363614dd 100644
--- a/doc/lispref/macros.texi
+++ b/doc/lispref/macros.texi
@@ -480,15 +480,17 @@ Eval During Expansion
Another problem can happen if the macro definition itself
evaluates any of the macro argument expressions, such as by calling
-@code{eval} (@pxref{Eval}). You have to take into account that the
-context of the caller is not accessible at that time since the macro expansion
-may take place long before the code is executed. Also if your macro definition
-does not use @code{lexical-binding} its own variables may hide the
-user's variables, if the user happens to use a
-variable with the same name as one of the macro arguments. Inside the
-macro body, the macro argument binding is the most local binding of this
-variable, so any references inside the form being evaluated do refer to
-it. Here is an example:
+@code{eval} (@pxref{Eval}). You have to take into account that macro
+expansion may take place long before the code is executed, when the
+context of the caller (where the macro expansion will be evaluated) is
+not yet accessible.
+
+ Also, if your macro definition does not use @code{lexical-binding}, its
+formal arguments may hide the user's variables of the same name. Inside
+the macro body, the macro argument binding is the most local binding of
+such variable, so any references inside the form being evaluated do refer
+to it. Here is an example:
+
@example
@group
(defmacro foo (a)
@@ -510,9 +512,9 @@ Eval During Expansion
@code{x}, because @code{a} conflicts with the macro argument variable
@code{a}.
- Also the expansion of @code{(foo x)} above will return something
-different or signal an error when the code is compiled since in that case
-@code{(foo x)} is expanded during compilation whereas the execution of
+ Also, the expansion of @code{(foo x)} above will return something
+different or signal an error when the code is compiled, since in that case
+@code{(foo x)} is expanded during compilation, whereas the execution of
@code{(setq x 'b)} will only take place later when the code is executed.
To avoid these problems, @strong{don't evaluate an argument expression
--
2.30.2
^ permalink raw reply related [flat|nested] 4+ messages in thread