ecl/doc/ansi_evaluation.xml

<?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>