About Repeated Expansion

About Repeated Expansion

[Xue Fuqiao]

The GNU Emacs Lisp manual(http://www.gnu.org/software/emacs/manual/html_node/elisp/Repeated-Expansion.html#Repeated-Expansion) says:

 Here is an example of how such side effects can get you into trouble:
     (defmacro empty-object ()
       (list 'quote (cons nil nil)))
     (defun initialize (condition)
       (let ((object (empty-object)))
         (if condition
             (setcar object condition))
         object))
If initialize is interpreted, a new list (nil) is constructed each time initialize is called. Thus, no side effect survives between calls. If initialize is compiled, then the macro empty-object is expanded during compilation, producing a single “constant” (nil) that is reused and altered each time initialize is called. 

It says if `initialize' is compiled, the (nil) will be reused and altered each time `initialize' is called.  But there is no expression that alters `empty-object', why will it be altered?
-- 
Best regards.

Re: About Repeated Expansion

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 831 bytes --]

() Xue Fuqiao <xfq.free@gmail.com>
() Sun, 30 Dec 2012 14:30:07 +0800

   The GNU Emacs Lisp manual([LONG-URL]) says:

BTW, here is the corresponding info node for LONG-URL:

 (elisp) Repeated Expansion

aka

 (info "(elisp) Repeated Expansion")

I think it would be cool if people posted this in place of (or in
addition to) LONG-URL.  That would help offline folks to follow along.
(The second form is for easy ‘C-x C-e’ in Emacs.)

-- 
Thien-Thi Nguyen ..................................... GPG key: 4C807502
.                  NB: ttn at glug dot org is not me                   .
.                 (and has not been since 2007 or so)                  .
.                        ACCEPT NO SUBSTITUTES                         .
........... please send technical questions to mailing lists ...........

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: About Repeated Expansion

[Xue Fuqiao]

On Sun, 30 Dec 2012 10:10:42 +0100
Thien-Thi Nguyen <ttn@gnuvola.org> wrote:

> I think it would be cool if people posted this in place of (or in
> addition to) LONG-URL.  That would help offline folks to follow along.
> (The second form is for easy ‘C-x C-e’ in Emacs.)

Thanks for your advice. 

I'm using the bzr trunk and emacs-24 branch, and I don't have Emacs 24.2.  The Emacs manuals(especially the elisp manual) is changing fast, so my info file is newer than the version in the GNU website.  I'm not sure whether the node name of the two are the same.

I'll download the latest stable manuals later.
-- 
Best regards.

Re: About Repeated Expansion

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 3087 bytes --]

() Xue Fuqiao <xfq.free@gmail.com>
() Sun, 30 Dec 2012 18:06:38 +0800

   I'm using the bzr trunk and emacs-24 branch, and I don't have Emacs
   24.2.  The Emacs manuals(especially the elisp manual) is changing
   fast, so my info file is newer than the version in the GNU website.
   I'm not sure whether the node name of the two are the same.

That's OK (see below).

   I'll download the latest stable manuals later.

I rather think it is advantageous to everyone to discuss the newer
manuals, precisely because they are changing.

If we discuss the old, any problems that arise in them may or may not
have been already fixed in the new.  If we discuss the new, any such
problems can be addressed on a more timely basis.

These messages are archived, so whatever the xref style (URL or info
node name), there is always the risk of it going stale, making life more
interesting for future m.l. archeologists.  Links to new manuals reduces
that risk.

The last thing to consider (before getting down from this meta level
discussion and back to the topic), is that the rate of change of any
particular topic usually depends on its maturity.  Topics like bidi
support and window configuration DSL finangling are newer, so one
expects quite some document churn there.  Topics like macros are very
(decades) mature, so one expects incremental improvements only, there.

But why speculate?  This is free software!  The (.texi) source, the
ChangeLog files and the repo are all there to peruse.  E.g., ‘C-x v g’
in doc/lispref/macros.texi (in a local Git repo) tells me that the node
"Repeated Expansion" was last touched in early September 2007.  The
ChangeLog file in that dir tells me macros.texi has undergone small
changes in style and diction in the intervening years w/ few changes in
organization or scope.  From all this, which admittedly took 15 minutes
to procure and surmise, i have convinced myself (and maybe yoU?) that

 (info "(elisp) Repeated Expansion")

is a high-quality, long-lasting way to point to those docs.  (Now, watch
someone change it just to show how foolish ttn sounds, spewing... :-D)

                               - * - * -

Oops, i got a little carried away there.  Back on topic: First off, the
agent of change in this example is ‘setcdr’.  Next, the phrase:

 is compiled, then the macro @code{empty-object} is expanded

could probably be made more precise to emphasize that it is not
‘empty-object’ per se that is expanded (which actually makes no sense),
but the call to it:

 is compiled, then the macro call @code{(empty-object)} is expanded

Note the parens in the ‘@code’ command.  Does that help?

-- 
Thien-Thi Nguyen ..................................... GPG key: 4C807502
.                  NB: ttn at glug dot org is not me                   .
.                 (and has not been since 2007 or so)                  .
.                        ACCEPT NO SUBSTITUTES                         .
........... please send technical questions to mailing lists ...........

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: About Repeated Expansion

[Xue Fuqiao]

On Sun, 30 Dec 2012 16:16:43 +0100
Thien-Thi Nguyen <ttn@gnuvola.org> wrote:

> These messages are archived, so whatever the xref style (URL or info
> node name), there is always the risk of it going stale, making life more
> interesting for future m.l. archeologists.  Links to new manuals reduces
> that risk.
My English is poor.  What does `m.l.' mean?  Does it mean `mailing list'?

> From all this, which admittedly took 15 minutes
> to procure and surmise, i have convinced myself (and maybe yoU?) that
> 
>  (info "(elisp) Repeated Expansion")
> 
> is a high-quality, long-lasting way to point to those docs.
Sorry for my laziness.

> Note the parens in the ‘@code’ command.  Does that help?
I see, thanks.
-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

Re: About Repeated Expansion

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

() Xue Fuqiao <xfq.free@gmail.com>
() Mon, 31 Dec 2012 06:49:46 +0800

   My English is poor.

It doesn't seem that way to me.

   What does `m.l.' mean?  Does it mean `mailing list'?

Yes.  Sorry for slipping into slang there.

   Sorry for my laziness.

No worries.

   I see, thanks.

Glad to help.  It's always nice to explore Emacs Lisp programming.

-- 
Thien-Thi Nguyen ..................................... GPG key: 4C807502
.                  NB: ttn at glug dot org is not me                   .
.                 (and has not been since 2007 or so)                  .
.                        ACCEPT NO SUBSTITUTES                         .
........... please send technical questions to mailing lists ...........

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

RE: About Repeated Expansion

[Drew Adams]

> The GNU Emacs Lisp 
> manual(http://www.gnu.org/software/emacs/manual/html_node/elis
> p/Repeated-Expansion.html#Repeated-Expansion) says:
> 
>  Here is an example of how such side effects can get you into trouble:
>      (defmacro empty-object ()
>        (list 'quote (cons nil nil)))
>      (defun initialize (condition)
>        (let ((object (empty-object)))
>          (if condition
>              (setcar object condition))
>          object))
>
>  If initialize is interpreted, a new list (nil) is constructed 
>  each time initialize is called. Thus, no side effect survives 
>  between calls.  If initialize is compiled, then the macro 
>  empty-object is expanded during compilation, producing a 
>  single "constant" (nil) that is reused and altered each time 
>  initialize is called. 
> 
> It says if `initialize' is compiled, the (nil) will be reused 
> and altered each time `initialize' is called.  But there is 
> no expression that alters `empty-object', why will it be altered?

Yes, there is such an expression: (setcar object condition)

The empty object is a cons cell.  It is initialized with nil as its car and nil
as its cdr.  Each time `initialize' is called, it does (setcar object
condition), where OBJECT is precisely that same cons cell.  IOW, each time it is
called it sets the car of that cons cell to the value of CONDITION.

The point of this text is that macro `empty-object' returns a particular cons
cell, and if compiled that cons cell, not a call to `empty-object', is inserted
as a constant in the resulting byte-code.  So when `initialize' is then invoked,
its seeming call to `empty-object' just provides that same cons cell, which then
gets modified by `setcar'.

In interpreted code, the invocation of `empty-object' is still present, and it
returns a new cons cell (which then gets its car set).

Re: About Repeated Expansion

[Xue Fuqiao]

On Sun, 30 Dec 2012 09:07:29 -0800
"Drew Adams" <drew.adams@oracle.com> wrote:

> So when `initialize' is then invoked,
> its seeming call to `empty-object' just provides that same cons cell, which then
> gets modified by `setcar'.

Thanks, I see.
-- 
Best regards