compile
compile name &optional definition → function, warnings-p, failure-p
name—a function name, or nil.
25.1.0 5definition—a lambda expression or a function. The default is the function definition of name if it names a function, or the macro function of name if it names a macro. The consequences are undefined if no definition is supplied when the name is nil.
25.1.0 6function—the function-name, or a compiled function.
warnings-p—a generalized boolean.
failure-p—a generalized boolean.
Compiles an interpreted function. Moon: Intent is compilation envirionment = startup environment. Just delete this phrase, I think. in the current \term{dynamic environment}.
compile produces a compiled function from definition. If the definition is a lambda expression, it is coerced to a function. If the definition is already a compiled function, compile either produces that function itself (i.e., is an identity operation) or an equivalent function.
Editor: KMP: There are a number of ambiguities here that still need resolution.!!!
Cases of interest:
Given: (defmacro foist (x) `(car ,x))
What do these do:
(compile 'foist (macro-function 'foist))
(compile 'foist (symbol-function 'foist))
(compile 'foist '(lambda (x y) (+ x y)))If the name is nil, the resulting compiled function is returned directly as the primary value. If a non-nil name is given, then the resulting compiled function replaces the existing function definition of name and the name is returned as the primary value; if name is a symbol that names a macro, its macro function is updated and the name is returned as the primary value.
I moved this paragraph so it isn't in the middle of the discussion
of compiler diagnostics. --sjl 7 Mar 92 Constants -> Literal objects. -kmp 15-Jan-91Literal objects appearing in code processed by the compile function are neither copied nor coalesced. The code resulting from the execution of compile references objects that are eql to the corresponding objects in the source code.
compile is permitted, but not required, to establish a handler for conditions of type error. For example, the handler might issue a warning and restart compilation from some implementation-dependent point in order to let the compilation proceed without manual intervention.
The secondary value, warnings-p, is false clarify ``compiler diagnostics'' --sjl 7 Mar 92
if no compiler diagnostics were issued, and \term{true} otherwise.if no conditions of type error or warning were detected by the compiler, and true otherwise.
The tertiary value, failure-p, is false clarify ``compiler diagnostics'' --sjl 7 Mar 92
if no compiler diagnostics other than \term{style warnings} were issued.
A value of \term{true} indicates that there were serious compiler diagnostics
issued, or that other \term{conditions} \oftype{error} or \typeref{warning}
(but not \oftype{style-warning}) were signaled during compilation.if no conditions of type error or warning (other than style-warning) were detected by the compiler, and true otherwise.
(defun foo () "bar") → FOO
(compiled-function-p #'foo) → implementation-dependent
(compile 'foo) → FOO
(compiled-function-p #'foo) → true
(setf (symbol-function 'foo)
(compile nil '(lambda () "replaced"))) → #<Compiled-Function>
(foo) → "replaced"
(defun foo ...) \EV foo ;A function definition.
(compile 'foo) \EV foo ;Compile it.
;Now foo runs faster.
*error-output*, *macroexpand-hook*.
The presence of macro definitions and proclamations.
The consequences are undefined if the lexical environment surrounding the function to be compiled contains any bindings other than those for macros, symbol macros, or declarations.
The consequences are undefined if the \term{function} to be compiled was defined in a \term{non-null lexical environment}.
The consequences are unspecified if the \term{function} is already a \term{compiled function}.
should be an error signaled if name is nil and no definition is supplied. also if function is already compiled. ERROR and WARNING conditions may be signaled within COMPILE or COMPILE-FILE, including arbitrary errors which may occur due to compile-time processing of (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) forms or macro expansion.
The following information is mostly redundant with info in the chapter 3 concept section, and contains some inconsistencies. Better to just put in a cross-reference. --sjl 4 mar 92 \issue{COMPILER-DIAGNOSTICS:USE-HANDLER} The following list considers only those conditions signaled by the compiler as opposed to within the compiler. An error \oftype{error} might be signaled by the compiler in situations where the compilation cannot proceed without intervention. Examples include file open errors and syntax errors. An error \oftype{warning} might be signaled by the compiler in situations where the standard explicitly states that a warning must, should, or might be signaled. Also, an error \oftype{warning} might be signaled by the compiler in situations where the compiler can determine that a situation with undefined consequences or that would cause an error to be signaled would result at runtime. Examples include violation of type declarations, \term{assigning} or \term{binding} a \term{constant variable}, calling a built-in Lisp function with the wrong number of arguments or malformed keyword argument lists, referencing a variable declared \declref{ignore}, and the usage of unrecognized declaration specifiers. The compiler is permitted to signal errors \oftype{style-warning} about matters of programming style. Although \term{style warnings} might be signaled in these situations, no implementation is required to signal them. However, if an implementation does choose to signal an error about matters of programming style, that error is \oftype{style-warning} and is signaled by a call to \funref{warn}. Examples include redefinition of a \term{function} with a different argument list, calling a \term{function} with the wrong number of arguments, \term{accessing} unreferenced local variables not declared \declref{ignore}, and usage of declaration specifiers described in the standard but ignored by the compiler. \issue{COMPILER-WARNING-STREAM} This is now implied by the remarks about using WARN above. \funref{compile} is permitted to issue warnings through \term{error output}. \endissue{COMPILER-WARNING-STREAM} \endissue{COMPILER-DIAGNOSTICS:USE-HANDLER}
For information about errors detected during the compilation process, see Section 3.2.5 (Exceptional Situations in the Compiler).
None.