39 | | !AbclScriptEngine implements the {{{javax.script.Compilable}}} interface. Currently as of 2009-05-11 it only supports compilation using temporary files. It used to support compilation in-memory using the Lisp runtime compiler, but it had some issues - its behavior could not be assimilated to the temp-file-based in all cases, and thus support for it has been dropped. Compiled code, returned as a {{{javax.script.CompiledScript}}}, is read, compiled and executed by default in the ABCL-SCRIPT-USER package, like evaluated code. Differently from evaluated code, though, due to the way the ABCL compiler works, compiled code contains no reference to top-level self-evaluating objects (like numbers or strings). Thus, when evaluated, a piece of compiled code will return the value of the last non-self-evaluating form: for example the code "(do-something) 42" will return 42 when interpreted, but will return the result of (do-something) when compiled and later evaluated. To ensure consistency of behavior between interpreted and compiled code, make sure the last form is always a compound form - at least (identity some-literal-object). Note that this issue should not matter in real code (in fact, the Common Lisp load function always returns T upon success; with JSR-223 this policy has been changed to make evaluation of small code snippets feasible). |
| 39 | !AbclScriptEngine implements the {{{javax.script.Compilable}}} interface. Currently as of 2009-05-11 it only supports compilation using temporary files. It used to support compilation in-memory using the Lisp runtime compiler, but it had some issues - its behavior could not be assimilated to the temp-file-based in all cases, and thus support for it has been dropped. Compiled code, returned as a {{{javax.script.CompiledScript}}}, is read, compiled and executed by default in the ABCL-SCRIPT-USER package, like evaluated code. Differently from evaluated code, though, due to the way the ABCL compiler works, compiled code contains no reference to top-level self-evaluating objects (like numbers or strings). Thus, when evaluated, a piece of compiled code will return the value of the last non-self-evaluating form: for example the code "(do-something) 42" will return 42 when interpreted, but will return the result of (do-something) when compiled and later evaluated. To ensure consistency of behavior between interpreted and compiled code, make sure the last form is always a compound form - at least (identity some-literal-object). Note that this issue should not matter in real code, where it is unlikely a top-level self-evaluating form will appear as the last form in a file (in fact, the Common Lisp load function always returns T upon success; with JSR-223 this policy has been changed to make evaluation of small code snippets feasible). |