/usr/share/mozart/doc/compiler/node1.html is in mozart-doc 1.4.0-8ubuntu1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>1 Introduction</TITLE><LINK href="ozdoc.css" rel="stylesheet" type="text/css"></HEAD><BODY><TABLE align="center" border="0" cellpadding="6" cellspacing="6" class="nav"><TR bgcolor="#DDDDDD"><TD><A href="index.html">- Up -</A></TD><TD><A href="node2.html#chapter.directives">Next >></A></TD></TR></TABLE><DIV id="chapter.intro"><H1><A name="chapter.intro">1 Introduction</A></H1><P> The Mozart Compiler is, in principle, only a special kind of evaluator. In general, an evaluator implements the mapping: </P><BLOCKQUOTE><P>source_text × environment -> value</P></BLOCKQUOTE><P> </P><DIV class="apropos"><P class="margin">Compiling Programs</P><P> Performing evaluation of Oz programs with a compiler has some advantages: </P><UL><LI><P>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 - strictly speaking - 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. </P></LI><LI><P>Programs may be translated into a more efficient representation. In the case of the Mozart Compiler, this consists of bytecode for the Mozart VM. </P></LI></UL><P> 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. </P></DIV><DIV class="apropos"><P class="margin">The Manual's Structure</P><P> The remainder of this chapter will describe what the state of the Mozart Compiler consists of, and what additional parameters compilation takes into account. <A href="node2.html#chapter.directives">Chapter 2</A> describes what programs the compiler accepts as input. <A href="node3.html#chapter.applications">Chapter 3</A> 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 <A href="node4.html#chapter.api">Chapter 4</A>. </P></DIV><P> Note that there is another widely used application of the compiler, namely the <EM>Oz Programming Interface</EM>. See <A href="../opi/node4.html#section.mozart">Section 4.6 of ``The Oz Programming Interface''</A> for a description. </P><DIV class="unnumbered"><H2><A name="label1">The Compiler's State</A></H2><P> This section describes the components of the compiler's internal state as well as their initial values. </P><DIV class="apropos"><P class="margin">Macro Definitions</P><P> The compiler stores a set of so-called <EM>macro names</EM>, used to control conditional compilation via macro directives such as <CODE><SPAN class="reference">\ifdef</SPAN></CODE> (see <A href="node2.html#section.directives.macro">Section 2.2</A>). </P></DIV><P id="section.macronames"> Initially, the set of macro names consists of entries describing the system's version number, for instance, when running Mozart 1.1.0, all of <CODE>Mozart_1</CODE>, <CODE>Mozart_1_1</CODE>, and <CODE>Mozart_1_1_0</CODE> are macro names. </P><DIV class="apropos"><P class="margin">Switches and Options</P><P> 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></DIV><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><P> The available switches, their initial settings and their effects on the compilation process are described in detail in <A href="node5.html#appendix.switches">Appendix A</A>. </P><DIV class="apropos"><P class="margin">The Environment</P><P> 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></DIV><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 <A href="../base/index.html">``The Oz Base Environment''</A>. </P><DIV class="apropos"><P class="margin">The Query Queue</P><P> 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 <EM>query queue</EM>.</P></DIV></DIV></DIV><TABLE align="center" border="0" cellpadding="6" cellspacing="6" class="nav"><TR bgcolor="#DDDDDD"><TD><A href="index.html">- Up -</A></TD><TD><A href="node2.html#chapter.directives">Next >></A></TD></TR></TABLE><HR><ADDRESS><A href="http://www.ps.uni-sb.de/~kornstae/">Leif Kornstaedt</A><BR><SPAN class="version">Version 1.4.0 (20110908185330)</SPAN></ADDRESS></BODY></HTML>
|