--- a
+++ b/ansi_evaluation.xml
@@ -0,0 +1,152 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE book [
+<!ENTITY % eclent SYSTEM "ecl.ent">
+%eclent;
+]>
+<book xmlns="http://docbook.org/ns/docbook" version="5.0" xml:lang="en">
+<chapter xml:id="ansi.evaluation-and-compilation">
+ <title>Evaluation and compilation</title>
+
+ <section xml:id="ansi.declarations">
+  <title>Declarations</title>
+
+  <section xml:id="ansi.declarations.optimize">
+   <title><function>OPTIMIZE</function></title>
+
+   <para>The <function>OPTIMIZE</function> declaration includes three concepts:
+   <function>DEBUG</function>, <function>SPEED</function>,
+   <function>SAFETY</function> and <function>SPACE</function>. 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.</para>
+
+   <para>&ECL; currently does not use all these declarations, but some of them
+   definitely affect the speed and behavior of compiled functions. For
+   instance, the <function>DEBUG</function> declaration, as shown in <xref
+   linkend="table.optimize.debug"/>, if the value of debugging is zero, the
+   function will not appear in the debugger and, if redefined, some functions
+   might not see the redefinition.</para>
+
+   <table xml:id="table.optimize.debug">
+    <title>Behavior for different levels of DEBUG</title>
+    <tgroup cols="5">
+     <thead>
+      <row>
+       <entry>Behavior</entry>
+       <entry>0</entry>
+       <entry>1</entry>
+       <entry>2</entry>
+       <entry>3</entry>
+      </row>
+     </thead>
+     <tbody>
+      <row>
+       <entry>Compiled functions in the same source file are called
+       directly</entry>
+       <entry>Y</entry>
+       <entry>Y</entry>
+       <entry>N</entry>
+       <entry>N</entry>
+      </row>
+      <row>
+       <entry>Compiled function appears in debugger backtrace</entry>
+       <entry>N</entry>
+       <entry>N</entry>
+       <entry>Y</entry>
+       <entry>Y</entry>
+      </row>
+      <row>
+       <entry>All functions get a global entry, that is, SI:C-LOCAL is
+       ignored.</entry>
+       <entry>N</entry>
+       <entry>N</entry>
+       <entry>Y</entry>
+       <entry>Y</entry>
+      </row>
+     </tbody>
+    </tgroup>
+   </table>
+
+   <para>A bit more critical is the value of <function>SAFETY</function>
+   because as shown in Table <xref linkend="table.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
+   <function>SAFETY</function>, and invoke <function>RPLACA</function>, the
+   consequences are unspecified.</para>
+
+   <table xml:id="table.optimize.safety">
+    <title>Behavior for different levels of SAFETY</title>
+    <tgroup cols="5">
+     <thead>
+      <row>
+       <entry>Behavior</entry>
+       <entry>0</entry>
+       <entry>1</entry>
+       <entry>2</entry>
+       <entry>3</entry>
+      </row>
+     </thead>
+     <tbody>
+      <row>
+       <entry>The compiler generates type checks for the arguments of a lambda
+       form, thus enforcing any type declaration written by the user.</entry>
+       <entry>N</entry>
+       <entry>Y</entry>
+       <entry>Y</entry>
+       <entry>Y</entry>
+      </row>
+      <row>
+       <entry>The value of an expression or a variable declared by the user is
+       assumed to be right.</entry>
+       <entry>Y</entry>
+       <entry>Y</entry>
+       <entry>N</entry>
+       <entry>N</entry>
+      </row>
+      <row>
+       <entry>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 CAR, CDR, etc</entry>
+       <entry>Y</entry>
+       <entry>Y</entry>
+       <entry>N</entry>
+       <entry>N</entry>
+      </row>
+      <row>
+       <entry>We believe types defined before compiling a file not change
+       before the compiled code is loaded.</entry>
+       <entry>Y</entry>
+       <entry>Y</entry>
+       <entry>N</entry>
+       <entry>N</entry>
+      </row>
+      <row>
+       <entry>Arguments in a lisp form are assumed to have the appropriate types
+       so that the form will not fail.</entry>
+       <entry>Y</entry>
+       <entry>N</entry>
+       <entry>N</entry>
+       <entry>N</entry>
+      </row>
+      <row>
+       <entry>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 PATHNAME-TYPE, CAR, REST,
+       etc.</entry>
+       <entry>Y</entry>
+       <entry>N</entry>
+       <entry>N</entry>
+       <entry>N</entry>
+      </row>
+     </tbody>
+    </tgroup>
+   </table>
+
+  </section>
+ </section>
+
+ <xi:include href="ref_c_evaluation.xml" xpointer="ansi.evaluation.c-dict" xmlns:xi="http://www.w3.org/2001/XInclude"/>
+
+</chapter>
+</book>