Re: [SOLVED with `eval']: Why I cannot use this variable in macro call from function?

[tomas]

On Wed, Jun 09, 2021 at 05:39:25PM +0300, Jean Louis wrote:
> ;; -*- lexical-binding: t; -*-
> * tomas@tuxteam.de <tomas@tuxteam.de> [2021-06-09 14:35]:
> > On Wed, Jun 09, 2021 at 01:56:45PM +0300, Jean Louis wrote:
> > > * tomas@tuxteam.de <tomas@tuxteam.de> [2021-06-09 11:54]:
> > > > On Wed, Jun 09, 2021 at 11:22:38AM +0300, Jean Louis wrote:
> > > > > * tomas@tuxteam.de <tomas@tuxteam.de> [2021-06-09 10:40]:
> > > > > > You snipped the (for me) interesting part: did you notice how
> > > > > > `eval' jumps over the local declaration?
> > > > > 
> > > > > Do you mean variables within `let'?
> > > > 
> > > > Yes, it doesn't see them :)
> > > 
> > > Maybe in theory it does not see, but in reality it does see it as
> > > `list' is evaluated before `eval', so the interned `rcd-symbol' and
> > > variable `description' they get evaluated before `eval'.
> 
> > That sentence doesn't make any sense to me. It does or it doesn't.
> 
> Well, I get confused too, you said that it does not see, but it is
> obvious that it does see.
> 
> > I propose to you the next experiment:
> > 
> > * experiment 3
> > 
> >   (let ()
> >     (let ((x 42))
> >       (eval '(progn (setq x 43) (message "in eval: x is %S" x)))
> >       (message "inner let: x is %S" x))
> >     (message "outer let: x is %S" x))
> > 
> > (you might have to switch to the *Messages* buffer to see all three
> > messages).
> 
> The outer scope does not see the inner scope.
> 
> Then the buffer *Backtrace* jumps up:
> 
> Debugger entered--Lisp error: (void-variable x)
>   (message "outer let: x is %S" x)
>   (let nil (let ((x 42)) (eval '(progn (setq x 43) (message "in eval: x is 
> %S" x))) (message "inner let: x is %S" x)) (message "outer let: x is %S" x))
>   eval((let nil (let ((x 42)) (eval '(progn (setq x 43) (message "in eval: x 
> is %S" x))) (message "inner let: x is %S" x)) (message "outer let: x is %S" 
> x)) nil)
>   elisp--eval-last-sexp(nil)
>   eval-last-sexp(nil)
>   funcall-interactively(eval-last-sexp nil)
>   call-interactively(eval-last-sexp nil nil)
>   command-execute(eval-last-sexp)

Oh, that is interesting. For me (this is copied off the *Messages* buffer;
I started Emacs anew to make sure no global definition of x lingers
around; to make extra sure, I just eval'ed x before: it throws the
expected void-variable x):

  in eval: x is 43
  inner let: x is 42
  outer let: x is 43
  "outer let: x is 43"

This is what I actually expect: the setq whithin the eval does set x's
global (or buffer-local, if there is one) value. It doesn't touch the
lexical value, because it doesn't know about it.

> > What are the results? Do they correspond to your expectations? If
> > not, why not?
> 
> I did not have any expectations for that piece of code and that
> one does not generate new global variables to return the symbol
> for history, which is what I need, and what is solved with `eval'
> nicely.
> 
> Look here:
> 
> (let ((x 42))
>   (eval (list 'progn (setq x 43) (message "in eval: x is %S" x)))) ⇒ "in 
> eval: x is 43"

It seems you have fun generating intentionally obfuscated code. Eval
is a function, so its argument is evaluated. Let's see...

  (list ; a function
    'progn ; (quote progn) evaluates to the symbol progn
    (setq x 43) ; evaluates to 43 SIDE EFFECT: set x to 43 at some 
global/buffer-local level
    (message "...") ; evaluates to "..." SIDE EFFECT print "..." to *Messages*

What eval "sees" at the end is

  (eval '(progn 43 "in eval: x is 43"))

which evaluates to "in eval: x is 43".

On the way to there, two side effects happened. The symbol x was bound to 43 in 
some
(global or buffer-local) symbol table (obarray), probably "before" (message ...)
happens (I've assumed so when substituting-in the x there), and something got
printed to *Messages*. Go look there: you'll probably find two copies of
"in eval: x is 43". The one is the side effect, the other the p from the REPL.

> that obviously does work nicely as the list gets evaluated before eval
> receives it. At least I assume it is so, according to learning about
> the LISP in general.

If it works nicely, we're all in agreement.

I'll have to stop here. Other things demand my attention, and I just can't
keep up with your bandwidth.

So happy hacking!

Cheers
 - t

signature.asc
Description: Digital signature