<!--
  - Author:
  -   Leif Kornstaedt <kornstae@ps.uni-sb.de>
  -
  - Copyright:
  -   Leif Kornstaedt, 1998
  -
  - Last change:
  -   $Date$ by $Author$
  -   $Revision$
  -
  - This file is part of Mozart, an implementation of Oz 3:
  -   http://www.mozart-oz.org
  -
  - See the file "LICENSE" or
  -   http://www.mozart-oz.org/LICENSE.html
  - for information on usage and redistribution
  - of this file, and for a DISCLAIMER OF ALL
  - WARRANTIES.
  -
  -->

<Chapter id="chapter.intro">
  <Title/Introduction/
  <P>
    The Mozart Compiler is, in principle, only a special kind of evaluator.
    In general, an evaluator implements the mapping:
    <Math.Choice display>
      <Math type=html>source_text &#215; environment -> value</Math>
      <Math type=latex>\mbox{source\_text} \times \mbox{environment}
      \rightarrow \mbox{value}</Math>
    </Math.Choice>
  <Para class=apropos><Title/Compiling Programs/
    Performing evaluation of Oz programs with a compiler has some
    advantages:
    <List>
      <Item>
	Programs with statically discoverable errors are rejected.  Apart
	from syntax errors and undeclared variables, this also includes
	discouraged uses of the language that are not&emdash;strictly
	speaking&emdash;necessarily errors.  For instance, applying a
	procedure with the wrong number of arguments does raise a
	catchable exception, but may be reported as an error.
      <Item>
	Programs may be translated into a more efficient representation.
	In the case of the Mozart Compiler, this consists of bytecode for
	the Mozart VM.
    </List>
    For correct programs, both these steps are transparent to the user,
    but due to them the transformation has actually more parameters and
    output than the general evaluator illustrated above.
  <Para class=apropos><Title/The Manual's Structure/
    The remainder of this chapter will describe what the state of the Mozart
    Compiler consists of, and what additional parameters compilation takes
    into account.  <Ptr to="chapter.directives"> describes what programs
    the compiler accepts as input.  <Ptr to="chapter.applications">
    describes two applications of the compiler, namely the batch compiler,
    which is invoked from the command line, and the compiler panel, which
    is a graphical interface to the compiler's state.  Both of these are
    implemented using the compiler's Application Programmer's Interface,
    which is described in detail in <Ptr to="chapter.api">.
  <P>
    Note that there is another widely used application of the compiler,
    namely the <Def/Oz Programming Interface/.  See <Ptr.Extern
    to="ozdoc:opi" key="section.mozart"> for a description.
  <Section class=unnumbered>
    <Title/The Compiler's State/
    <P>
      This section describes the components of the compiler's internal
      state as well as their initial values.
    <Para class=apropos><Title/Macro Definitions/
      The compiler stores a set of so-called <Def/macro names/, used to
      control conditional compilation via macro directives such as <<\ifdef>>
      (see <Ptr to="section.directives.macro">).
    <P id="section.macronames">
      Initially, the set of macro names consists of entries describing the
      system's version number, for instance, when running Mozart&nbsp;1.1.0,
      all of <<Mozart_1>>, <<Mozart_1_1>>, and <<Mozart_1_1_0>> are macro
      names.
    <Para class=apropos><Title/Switches and Options/
      The compiler's behaviour is influenced by a number of boolean switches
      and non-boolean options.  While the switch settings can conveniently
      be changed by several methods as described later, the options are
      only accessible to users of the application programmer's interface.
    <P>
      The active switch settings are given by a mapping from switch names
      to boolean values.  The compiler manages a stack of switch states,
      the top element of which is taken as the active state.  This allows
      to temporarily escape into a different mode of compiler operation.
    <P>
      The available switches, their initial settings and their
      effects on the compilation process are described in detail
      in <Ptr to="appendix.switches">.
    <Para class=apropos><Title/The Environment/
      The Oz compiler does not take the environment as input for each
      evaluation as was illustrated above, but stores its active environment.
      This may be extended as a side-effect of the compilation, and it may
      be replaced by other environments at will.
    <P>
      An environment is a mapping from variable print names to arbitrary
      Oz values.  Initially, the environment consists of the variables
      defined by the Oz Base Environment&nbsp;<Ptr.Extern to="ozdoc:base">.
    <Para class=apropos><Title/The Query Queue/
      Since the Oz compiler has internal state, it is not implemented
      as a function as described above, but as an active object that
      sequentializes all requests made to it via a <Def/query queue/.
</Chapter>
