Runtime evaluation: Difference between revisions

m (→‎{{header|Tcl}}: indicate why a limit is a good idea)
Line 20:
</pre>
=={{header|Common Lisp}}==
 
{{incorrect|Common Lisp|It does not discuss sandboxing, resource limiting, or debugging.}}
<lang lisp>(eval '(+ 4 5))</lang>
 
Line 30:
(eval `(+ 4 ',a-number)))</lang>
 
Or you can construct a function and then call it. (If the function is used more than once, it would be good to use <code>[http://www.lispworks.com/documentation/HyperSpec/Body/f_cmp.htm compile]</code> instead of <code>[http://www.lispworks.com/documentation/HyperSpec/Body/f_eval.htm eval]</code>, which compiles the code before returning the function. <code>eval</code> is permitted to compile as well, but <code>compile</code> requires it.)
 
<lang lisp>(defun add-four-by-function (a-number)
Line 42:
<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.
 
=={{header|Groovy}}==