The discussion in this topic is aimed at better understanding how the principle "there is no difference between code and data in LISP" works in practice.
My intention was to "execute" comand-variables containing LISP code as their values (like variable "command") so that all variables which appear in this code assume local values within current lexical environment during the execution. And macro "true-eval" does this job! It may fail in some other situations like in your input-output operators (in some implementations). In my implementation (Allegro CL),
both your input-output codes with EVAL and TRUE-EVAL work identically without problems.
Behaviour of EVAL inside LET
Re: Behaviour of EVAL inside LET
To understand LISP, you must first understand LISP.
Re: Behaviour of EVAL inside LET
Yes, for that macros are good.
But I've wanted to point the difference between a runtime evaluation and a macroexpansion out (beacuse I didn't know you don't want the normal evaluation). Try in Allegro CL to factor out what was in the loop.
vs.
At the second snippet insert the top-level forms one by one and maybe use compile which can be used by program, so it's relevant.
But I've wanted to point the difference between a runtime evaluation and a macroexpansion out (beacuse I didn't know you don't want the normal evaluation). Try in Allegro CL to factor out what was in the loop.
Code: Select all
(defun counted-result (i) (format t "~a> ~a~%" i (eval (read))))
(loop for i below 3 do (counted-result i))
Code: Select all
(defun counted-result (i) (format t "~a> ~a~%" i (true-eval (read))))
(loop for i below 3 do (counted-result i))
cl-2dsyntax is my attempt to create a Python-like reader. My mirror of CLHS (and the dark themed version). Temporary mirrors of aferomentioned: CLHS and a dark version.
Re: Behaviour of EVAL inside LET
I am not so advanced LISP user to understand
But macro TRUE-EVAL has indeed a strange behaviour. It cannot be applied to formal variables inside function definitions, an attempt to compile
gives an error unless "x" already has some value.
My suggestion to those who read this forum and who plan to improve/better implement such a great langage as LISP is to take more attention to the evaluation operations.
(:-))))the difference between a runtime evaluation and a macroexpansion out
But macro TRUE-EVAL has indeed a strange behaviour. It cannot be applied to formal variables inside function definitions, an attempt to compile
Code: Select all
(defun t-eval (x) (true-eval x) )
My suggestion to those who read this forum and who plan to improve/better implement such a great langage as LISP is to take more attention to the evaluation operations.
To understand LISP, you must first understand LISP.
Re: Behaviour of EVAL inside LET
Because the x gets evaluated during macroexpansion of the evaluate in macrolet, so you should have it quoted:
Code: Select all
(defun t-eval (x) (true-eval 'x))
cl-2dsyntax is my attempt to create a Python-like reader. My mirror of CLHS (and the dark themed version). Temporary mirrors of aferomentioned: CLHS and a dark version.
Re: Behaviour of EVAL inside LET
You can't do that, as a general rule. You're confusing symbols and variables -- they're not the same thing (except for "special" variables). Symbols are data objects used to name variables; a variable is just a memory address -- there's no way to link a symbol to an address in Lisp (you might be able to through the debugger interface, etc.), so you can't turn a symbol coming from outside into the same variable that was named by that symbol in a piece of source code. (And if you could, you'd break all sorts of things...)abvgdeika wrote:The discussion in this topic is aimed at better understanding how the principle "there is no difference between code and data in LISP" works in practice.
My intention was to "execute" comand-variables containing LISP code as their values (like variable "command") so that all variables which appear in this code assume local values within current lexical environment during the execution.