Jump to content

Runtime evaluation: Difference between revisions

Runtime evaluation (view source)

Revision as of 00:28, 21 July 2011

845 bytes removed ,  12 years ago
→‎{{header|Common Lisp}}: Merge the 2 Common Lisp sections into 1 section. We had 2 sections after a broken </lang> tag swallowed the 1st section, and I stupidly added a 2nd section.
(reword to avoid "executing programs" language)
(→‎{{header|Common Lisp}}: Merge the 2 Common Lisp sections into 1 section. We had 2 sections after a broken </lang> tag swallowed the 1st section, and I stupidly added a 2nd section.)
Line 124:
 
=={{header|Common Lisp}}==
The <tt>eval</tt> function evaluates Lisp code at runtime.
 
<lang lisp>(eval '(+ 4 5)) ; returns 9</lang>
 
returns 9.
 
In Common Lisp, programs are represented as trees (s-expressions). Therefore, it is easily possible to construct a program which includes externally specified values, particularly using backquote template syntax:
Line 139 ⟶ 138:
(funcall (eval '(lambda (n) (+ 4 n)))) a-number)</lang>
 
If your program came from a file or user input, then you have it as a string, and [http://www.lispworks.com/documentation/HyperSpec/Body/f_rd_rd.htm <code>read</code>] or <code>read-from-string</code> will convert it to s-expression form:
 
<lang lisp>(eval (read-from-string "(+ 4 5)"))</lang>
 
Common Lisp has lexical scope, but <code>eval</code> always evaluates “in the null lexical environment”. In particular, it<code>eval</code> does not inherit the lexical environmentvariables from the enclosing code. (Note that <code>eval</code> is an ordinary function and as such does not have access to that environment anyway.)
 
<lang lisp>(let ((x 1))
(eval `(+ x 1))) ; this will fail unless x is a special variable or has a dynamic binding</lang>
 
There are no sandboxing facilities in standard Common Lisp. Because CL has so many shared mutable objects (packages and symbols), no attempt to design a CL sandbox (other than at the OS process level<!-- ; see e.g. [telnet://prompt.franz.com prompt.franz.com] (not mentioning because this seems to be down now)-->) has yet succeeded.▼
 
There are no standardized debugging facilities specific to the <code>eval</code> operation itself, but code evaluted may be affected by the current [http://www.lispworks.com/documentation/HyperSpec/Body/03_c.htm global declarations], particularly the [http://www.lispworks.com/documentation/HyperSpec/Body/d_optimi.htm <code>optimize</code> declaration]'s <code>debug</code> and <code>safety</code> qualities.▼
 
The <tt>eval</tt> function evaluates a form at runtime. The form can be Lisp code in a list. Here, I just quote a list. You can use any list operations to make a list.
 
<lang lisp>(eval '(format t "~%Rosetta Code"))
 
;; When the code is in a variable:
(let ((code '(format t "~%Rosetta Code")))
(eval code))
 
;; When the code is in a string:
(eval (read-from-string "(format t \"~%Rosetta Code\")"))</lang>
 
<tt>eval</tt> runs its argument in a ''null lexical environment''. This means that the code inside the <tt>eval</tt> cannot see lexical variables from outside the <tt>eval</tt>.
 
<lang lisp>(let ((x 11) (y 22))
Line 168 ⟶ 148:
(format t "~%x + y = ~a" (eval '(+ x y))))</lang>
 
One way to fix the error is to use <tt>(declare (special x y))</tt> for dynamic variables; but the easier and shorter way is to insert the values of x and y intowith the codebackquote beforetemplate calling <tt>eval</tt>syntax.
 
<lang lisp>(let ((x 11) (y 22))
(format t "~%x + y = ~a" (eval `(+ ,x ,y))))</lang>
 
▲There are no sandboxing facilities in standard Common Lisp. Because CL has so many shared mutable objects (packages and symbols), no attempt to design a CL sandbox (other than at the OS process level<!-- ; see e.g. [telnet://prompt.franz.com prompt.franz.com] (not mentioning because this seems to be down now)-->) has yet succeeded.
The above example evaluates <tt>(+ 11 22)</tt>, because the backquote inserted the values of x and y before <tt>eval</tt> got the code. <tt>eval</tt> passes the return value, so the code outputs <tt>x + y = 33</tt>.
 
▲There are no standardized debugging facilities specific to the <code>eval</code> operation itself, but code evaluted may be affected by the current [http://www.lispworks.com/documentation/HyperSpec/Body/03_c.htm global declarations], particularly the [http://www.lispworks.com/documentation/HyperSpec/Body/d_optimi.htm <code>optimize</code> declaration]'s <code>debug</code> and <code>safety</code> qualities.
 
=={{header|E}}==
Anonymous user
Retrieved from "https://rosettacode.org/wiki/Special:MobileDiff/99951"
Cookies help us deliver our services. By using our services, you agree to our use of cookies.
More information