@node Evaluation and compilation
@section Evaluation and compilation

@subsection Compiler declaration @code{OPTIMIZE}
@cindex Compiler declarations
@lspindex optimize
@lspindex debug
@lspindex speed
@lspindex safety
@lspindex space

The @code{OPTIMIZE} declaration includes three concepts: @code{DEBUG},
@code{SPEED}, @code{SAFETY} and @code{SPACE}. Each of these declarations
can take one of the integer values 0, 1, 2 and 3. According to these
values, the implementation may decide how to compie or interpret a given
lisp form.

ECL currently does not use all these declarations, but some of them
definitely affect the speed and behavior of compiled functions. For
instance, the @code{DEBUG} declaration, as shown in
@ref{tab:optimize-debug}, the value of debugging is zero, the function
will not appear in the debugger and, if redefined, some functions might
not see the redefinition.

@float Table, tab:optimize-debug
@caption{Behavior for different levels of @code{DEBUG}}
@multitable {aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa} {a} {a} {a} {a}
@headitem Behavior
@tab 0
@tab 1
@tab 2
@tab 3

@item Compiled functions in the same source file are called directly
@tab Y
@tab Y
@tab N
@tab N

@item Compiled function appears in debugger backtrace
@tab N
@tab N
@tab Y
@tab Y

@item All functions get a global entry (SI:C-LOCAL is ignored)
@tab N
@tab N
@tab Y
@tab Y

@end multitable
@end float

A bit more critical is the value of @code{SAFETY} because as shown in
@ref{tab:optimize-safety}, it may affect the safety checks generated by
the compiler. In particular, in some circumstances the compiler may
assume that the arguments to a function are properly typed. For
instance, if you compile with a low value of @code{SAFETY}, and invoke
@code{RPLACA}, the consequences are unspecified.

@float Table, tab:optimize-safety
@caption{Behavior for different levels of @code{SAFETY}}
@multitable {aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa} {a} {a} {a} {a}
@headitem Behavior
@tab 0
@tab 1
@tab 2
@tab 3

@item The compiler generates type checks for the arguments of a lambda form, thus enforcing any type declaration written by the user.
@tab N
@tab Y
@tab Y
@tab Y

@item The value of an expression or a variable declared by the user is assumed to be right.
@tab Y
@tab Y
@tab N
@tab N

@item We believe type declarations and type inference and, if the type of a form is inferred to be right for a function, slot accessor, etc, this may be inlined. Affects functions like @code{CAR}, @code{CDR}, etc
@tab Y
@tab Y
@tab N
@tab N

@item We believe types defined before compiling a file not change before the compiled code is loaded.
@tab Y
@tab Y
@tab N
@tab N

@item Arguments in a lisp form are assumed to have the appropriate types so that the form will not fail.
@tab Y
@tab N
@tab N
@tab N

@item The slots or fields in a lisp object are accessed directly without type checks even if the type of the object could not be inferred (see line above). Affects functions like @code{PATHNAME-TYPE}, @code{CAR}, @code{REST}, etc.
@tab Y
@tab N
@tab N
@tab N

@end multitable
@end float

@subsection C Reference

@cppindex ecl_process_env
@deftypefn {@cind{}} cl_object cl_env_ptr ()
ECL stores information about each thread on a dedicated structure, which
is the process environment. A pointer to this structure can be retrieved
using the function or macro above. This pointer can be used for a
variety of tasks, such as defining special variable bindings,
controlling interrupts, retrieving function output values, etc.
@end deftypefn
