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

[tomas@tuxteam.de]

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

On Tue, Jun 08, 2021 at 11:47:09PM +0300, Jean Louis wrote:
> * tomas@tuxteam.de <tomas@tuxteam.de> [2021-06-08 23:23]:
> > OK. Since you can't go back in time, you can set the variable
> > for a part of the program which isn't yet compiled. Otherwise
> > you'd have to "un-compile" your program first, right?
> 
> Should I worry now? Sounds like I should
> 
> (defun my-hello (string)
>   (interactive "sYour name: ")
>   (eval (list 'message-box (concat "Hello " string))))
> 
> If that works dynamically then my function should also work. 

For some value of "work", yes. I propose doing the following
experiments:

Start always in a new "lisp interaction buffer". E.g. do

* Experiment 1

C-x b *my-new-experiment*, then M-x lisp-interaction-mode

First, type in

  lexical-binding

...with point at the end of the line (or the next line) C-x e to
eval this, make sure the minubuffer shows "t". We have lexical
binding.

Now enter this

  (let ((some-var 42)) ; just to set up some scope
    (eval '(setq that-other-var 43))
    (message "%S\n" that-other-var))

You'll see "43" in your minibuffer. We managed to set the dynamically
"defined" variable "that-other-var" to 43. Yay! Now enter

  that-other-var

...and again C-x e. Minibuffer says... 43. The variable escaped the
scope. Bad variable, but hey, that's how setq goes, no?

* Experiment 2

Make new lisp interaction buffer, as above. Make sure you have
lexical binding (when experimenting, always change at most one
thing at a time, right?). Now:

  (let ((some-var 42)
        (that-other-var 44)) ; bind that-other-var locally
    (eval '(setq that-other-var 43))
    (message "%S\n" that-other-var))

Again, minibuffer says 43. Now...

  that-other-var

...and C-x e. What does minibuffer say? Is that right or wrong?
Explain.

I guess you'll need a more differentiated model than just "works".
Works how? Do you want it to "work" like that? If yes, then fine.
And then there is the question of collaboration: if you want others
to understand your programs (and vice-versa), then there are even
more (!) criteria.

A very wise person [1] once said that he doesn't write programs
to get the computer to do what he wants, but to convince his
colleagues that the computer is doing the right thing.

Cheers

[1] ISTR that it was Donald Knuth.

 - t

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