diff lispref/macros.texi @ 7194:3112fb627aa0

*** empty log message ***

--- a/lispref/macros.texi	Fri Apr 29 10:07:31 1994 +0000
+++ b/lispref/macros.texi	Fri Apr 29 10:16:53 1994 +0000
@@ -224,8 +224,8 @@
 @end group
 @end example
 
-@findex , @{(with Backquote)}
-The special marker, @code{,}, inside of the argument to backquote,
+@findex , @r{(with Backquote)}
+The special marker @code{,} inside of the argument to backquote
 indicates a value that isn't constant.  Backquote evaluates the
 argument of @code{,} and puts the value in the list structure:
 
@@ -240,7 +240,7 @@
 @end group
 @end example
 
-@findex ,@@ @{(with Backquote)}
+@findex ,@@ @r{(with Backquote)}
 @cindex splicing (with backquote)
 You can also @dfn{splice} an evaluated value into the resulting list,
 using the special marker @code{,@@}.  The elements of the spliced list
@@ -278,7 +278,7 @@
 @end group
 @end example
 
-Emacs 18 had a bug which made the previous example fail.  The bug
+Emacs 18 had a bug that made the previous example fail.  The bug
 affected @code{,@@} followed only by constant elements.  If you are
 concerned with Emacs 18 compatibility, you can work around the bug like
 this:
@@ -320,9 +320,10 @@
 
 @cindex CL note---@samp{,}, @samp{,@@} as functions
 @quotation
-@b{Common Lisp note:} in Common Lisp, @samp{,} and @samp{,@@} are implemented
-as reader macros, so they do not require parentheses.  Emacs Lisp implements
-them as functions because reader macros are not supported (to save space).
+@b{Common Lisp note:} in Common Lisp, @samp{,} and @samp{,@@} are
+implemented as reader macros, so they do not require parentheses.  In
+Emacs Lisp they use function call syntax because reader macros are not
+supported (for simplicity's sake).
 @end quotation
 
 @node Problems with Macros
@@ -389,11 +390,26 @@
 will write noise words (such as @code{from}, @code{to}, and @code{do})
 in those positions in the macro call.)
 
-This macro suffers from the defect that @var{final} is evaluated on
-every iteration.  If @var{final} is a constant, this is not a problem.
-If it is a more complex form, say @code{(long-complex-calculation x)},
-this can slow down the execution significantly.  If @var{final} has side
-effects, executing it more than once is probably incorrect.
+Here's an equivalent definition simplified through use of backquote:
+
+@smallexample
+@group
+(defmacro for (var from init to final do &rest body)
+  "Execute a simple \"for\" loop.
+For example, (for i from 1 to 10 do (print i))."
+  (` (let (((, var) (, init)))
+        (while (<= (, var) (, final))
+          (,@@ body)
+          (inc (, var))))))
+@end group
+@end smallexample
+
+Both forms of this definition (with backquote and without) suffer from
+the defect that @var{final} is evaluated on every iteration.  If
+@var{final} is a constant, this is not a problem.  If it is a more
+complex form, say @code{(long-complex-calculation x)}, this can slow
+down the execution significantly.  If @var{final} has side effects,
+executing it more than once is probably incorrect.
 
 @cindex macro argument evaluation
 A well-designed macro definition takes steps to avoid this problem by
@@ -475,11 +491,12 @@
 
 The way to correct this is to use an uninterned symbol instead of
 @code{max} (@pxref{Creating Symbols}).  The uninterned symbol can be
-bound and referred to just like any other symbol, but since it is created
-by @code{for}, we know that it cannot appear in the user's program.
-Since it is not interned, there is no way the user can put it into the
-program later.  It will never appear anywhere except where put by
-@code{for}.  Here is a definition of @code{for} which works this way:
+bound and referred to just like any other symbol, but since it is
+created by @code{for}, we know that it cannot already appear in the
+user's program.  Since it is not interned, there is no way the user can
+put it into the program later.  It will never appear anywhere except
+where put by @code{for}.  Here is a definition of @code{for} that works
+this way:
 
 @smallexample
 @group