Page 1 of 1

Why the fexpr's internal variable's name couldn't be same as

Posted: Wed Jul 11, 2018 10:26 am
by nanxiao
Hi all,

Greeting from me!

When studying define-macro(http://www.newlisp.org/downloads/newlis ... fine-macro), I am a little confused with following statement:
Note that in fexprs, the danger exists of passing a parameter with the same variable name as used in the define-macro definition. In this case, the fexpr's internal variable would end up receiving nil instead of the intended value:

Code: Select all

;; not a good definition!

(define-macro (my-setq x y) (set x (eval y)))  

;; symbol name clash for x

(my-setq x 123)  → 123
x                → nil
Could anyone elaborate why the fexpr's internal variable's name couldn't be same as parameter's name?

Thanks very much in advance!

Best Regards
Nan Xiao

Re: Why the fexpr's internal variable's name couldn't be sam

Posted: Sun Jul 15, 2018 12:07 am
by ralph.ronnquist
Isn't it just a normal effect of dynamic binding; that any assignment always affects the "inner-most" variable of the name. It's not special to fexprs, but you can confuse yourself quite easily with "normal" lambdas if/when a lambda body refers to a variable outside its scope.

For example, if you have the following definitions (well, you wouldn't, but you can imagine it):

Code: Select all

(define (mysetx v) (set 'x v))
(define (myset x v) (mysetx v))
You'd get

Code: Select all

> (mysetx "hello")
"hello"
> x
"hello"
> (myset 'x 123)
123
> x
"hello"
Clear as mud :)

Re: Why the fexpr's internal variable's name couldn't be sam

Posted: Mon Jul 16, 2018 5:29 am
by nanxiao
Hi Ralph,

Got it! Thanks for your reply!

Best Regards
Nan Xiao