The Mozart Compiler: Leif Kornstaedt
The Mozart Compiler: Leif Kornstaedt
The Mozart Compiler: Leif Kornstaedt
Leif Kornstaedt
Version 1.3.2
June 15, 2006
Abstract
This document describes how to use the Oz Compiler in Mozart. This includes the descrip-
tions of the batch compiler and compiler panel as well as of the application programmer’s
interface to the compiler.
Credits
Mozart logo by Christian Lindig
License Agreement
This software and its documentation are copyrighted by the German Research Center for Artificial Intelligence
(DFKI), the Swedish Institute of Computer Science (SICS), and other parties. The following terms apply to
all files associated with the software unless explicitly disclaimed in individual files.
The authors hereby grant permission to use, copy, modify, distribute, and license this software and its doc-
umentation for any purpose, provided that existing copyright notices are retained in all copies and that this
notice is included verbatim in any distributions. No written agreement, license, or royalty fee is required for
any of the authorized uses. Modifications to this software may be copyrighted by their authors and need not
follow the licensing terms described here, provided that the new terms are clearly indicated on the first page
of each file where they apply.
IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE LIABLE TO ANY PARTY FOR DI-
RECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF
THE USE OF THIS SOFTWARE, ITS DOCUMENTATION, OR ANY DERIVATIVES THEREOF, EVEN
IF THE AUTHORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY WARRANTIES, INCLUD-
ING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR
A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. THIS SOFTWARE AND ITS DOCUMENTA-
TION ARE PROVIDED ON AN "AS IS" BASIS, AND THE AUTHORS AND DISTRIBUTORS HAVE NO
OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODI-
FICATIONS.
Contents
1 Introduction 1
2 Directives 3
2.1 Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Macro Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Standard Applications 5
3.1 The Batch Compiler . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 The Compiler Panel . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 The Oz Programming Interface . . . . . . . . . . . . . . . . . . . 6
A Compiler Switches 19
Introduction
The Mozart Compiler is, in principle, only a special kind of evaluator. In general, an
evaluator implements the mapping:
source_text × environment → value
• Programs with statically discoverable errors are rejected. Apart from syntax
errors and undeclared variables, this also includes discouraged uses of the lan-
guage 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.
• Programs may be translated into a more efficient representation. In the case of
the Mozart Compiler, this consists of bytecode for the Mozart VM.
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.
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. Chapter 2 describes what programs the compiler accepts as input. Chap-
ter 3 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 Chapter 4.
Note that there is another widely used application of the compiler, namely the Oz Pro-
gramming Interface. See Section Seeing the OPI from Mozart, (The Oz Programming
Interface) for a description.
Macro Definitions The compiler stores a set of so-called macro names, used to
control conditional compilation via macro directives such as \ifdef (see Section 2.2).
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 Mozart_1, Mozart_1_1, and
Mozart_1_1_0 are macro names.
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 envi-
ronments at will.
An environment is a mapping from variable print names to arbitrary Oz values. Ini-
tially, the environment consists of the variables defined by the Oz Base Environment “The
Oz Base Environment” .
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 query queue.
2
Directives
Directive Syntax The Mozart compiler understands the full syntax of Oz pro-
grams. Additionally, it also accepts directives in its input. A directive can start any-
where on a line and is introduced by a backslash; it always extends until the end of the
line.
Directives come in two flavors. So-called compiler directives provide a way to change
the compiler’s switches, whereas macro directives can be used for inserting files or
performing compilation conditionally. While macro directives may appear between
any two tokens in the input, the use of compiler directives underlies restrictions as
described below.
Compilation Units A single input file is split into a number of compilation units
as follows:
Note that this implies that compiler directives can only appear between top-level Oz
statements.
All compilation units in a file are processed sequentially.
\localSwitches
Save the current settings of all switches as well as the internal switch state stack if
no \localSwitches has occurred in the current input before, else do nothing. They
are automatically restored after the last compilation unit of the current input has been
processed.
\insert hfilenamei
is substituted by the contents of the referenced file. The ~user syntax is supported
under Unix for absolute file names. If the file name is relative, it is first resolved
against the directory in which the file containing the \insert resides, then against
all directories named in the OZPATH environment variable (which has standard PATH
syntax).
Macro Names Note that although macro names have the same syntax as Oz vari-
ables, there is absolutely no connection between macro names and Oz variables.
\define hvariablei
adjoins hvariablei to the set of macro names.
\undef hvariablei
removes hvariablei from the set of macro names.
\ifdef hvariablei
causes the text until the next balanced \else or \endif only to be compiled if hvariablei
is a macro name.
\ifndef hvariablei
caused the text until the next balanced \else or \endif to be ignored if hvariablei is
a macro name.
\else
causes the text until the next balanced \endif to be
• ignored, if the \else occurs after a text region that was being compiled;
• compiled, if the \else occurs after a text region that was being ignored.
\endif
terminates the active \ifdef or \ifndef. Every \ifdef and every \ifndef must be
terminated by a corresponding \endif.
3
Standard Applications
This chapter defines the standard applications of the compiler available with the Mozart
system: the batch compiler, the compiler panel, and its relation to the OPI.
The batch compiler ozc provides a command line interface to the compiler for batch
compilation. Batch compilation means that expressions (typically functor definitions)
are compiled and evaluated, and the resulting value is pickled.
Parameterization The command line options of ozc allow to customize the state
of the compiler to use for compilation. Options allow for configuration of the set
of defined macro names, to set all compiler switches, and to configure the compilation
environment. Pickling can be parameterized to using compression or headers that make
the resulting pickle executable. Further options influence the compilation mode: The
default, evaluating an expression and pickling the result, can be replaced by evaluation
of a statement, or intermediate results of compilation can be dumped. Finally, a special
mode allows to compute dependencies (in the form of included source files).
Reference The exact specification of command line options can be found in Chap-
ter The Oz Compiler: ozc, (Oz Shell Utilities) .
The Compiler Panel is another application of the compiler. The compiler defines the
notion of a compiler interface to communicate with the outside world. The compiler
panel is one such interface.
Interfaces A compiler interface received notification about the state of the compiler.
This includes its compilation state, but also its state of execution (how it manages its
query queue, what errors it reports, and whether a compilation succeeds). Chapter 4
describes how the API allows to define interfaces.
6 Chapter 3. Standard Applications
The Panel The compiler panel is a compiler interface that provides a graphical dis-
play of the compiler’s state. Its toplevel window has a menu that allows to enqueue
further compilation tasks and to configure how the the compiler’s state is displayed.
Furthermore, it features a set of notebook tabs for the different parts of its state.
Tabs The Messages tab provides access to a text display of compilation phase
tracking, and the warnings and errors reported. The Environment tab displays all
variables in the compilation environment. Each identifier can be clicked to execute an
action on its value; for instance, values can be shown or inspected. The set of actions
is configurable. The Switches tab displays the settings of every compiler switch
and option. Finally, the Query Queue tab displays the list of queries the compiler
currently executes.
Like all tools, the compiler panel has an API to enable applications to control it. The
module CompilerPanel, located at x-oz://system/CompilerPanel, exports
a class CompilerPanel.’class’ implementing the Listener interface, with the fol-
lowing methods.
init
init(+CompilerObject +IconifiedB <= false)
initializes a new instance of a compiler panel, associated with the compiler CompilerObject.
If IconifiedB is true, it is started with its toplevel window retracted.
close
close()
closes a compiler panel instance, also closing its window.
enqueue
enqueue(+Message)
enqueues a query to the compiler associated with the compiler panel instance. See
Chapter 4 for a specification of the values Message can take.
addAction
addAction(+NameV +ActionP)
adds an action to the menu of actions that can be performed on values in the environ-
ment. NameV is the name of the action as displayed in the menu while ActionP is a
unary procedure which will be passed the value when invoked.
The OPI (see “The Oz Programming Interface” ) runs a dedicated compiler instance
which receives all queries generated by feeding code in the OPI by default. It is avail-
able as OPI.compiler.
4
The compiler is available to Mozart applications through the module Compiler. This
chapter describes the functionality provided by that module and its classes.
First, a number of additional secondary type names used in this description is intro-
duced in Section 4.1, then the Compiler module is described in Section 4.2. The
material in that section should prove sufficient for most cases. The remainder of the
chapter is intended for advanced uses.
An arbitrary number of compilers may be instantiated, each with its own internal state,
and used concurrently. We distinguish between compiler engines, described in Sec-
tion 4.3, which store the state of a compiler and perform the compilation proper, and
compiler interfaces, described in Section 4.4, which allow to observe the activities of
compiler engines and to react to them. Both of these use the narrator/listener mecha-
nism described in Appendix B; familiarity with this is assumed.
Finally, examples are presented in Section 4.5; in particular, the provided abstractions
are explained in terms of compiler engines and interfaces.
This section describes additional secondary types used in the descriptions in this chap-
ter. The conventions defined in Section Description Format, (The Oz Base Environ-
ment) will be respected.
Coord stands for information about source coordinates. This is either unit if no information
is known or a tuple pos(FileName Line Column), where FileName is repre-
sented as an atom (” meaning ‘unknown’) and Line and Column are integers. Line
numbering begins at 1 and column numbering at 0; a column number of ~1 means
‘unknown’.
SwitchName is an atom which must be a valid switch name (see Appendix A).
Env represents an environment, represented as a record whose features are valid print names.
8 Chapter 4. Application Programmer’s Interface
evalExpression
{Compiler.evalExpression +V +Env ?KillP X}
evaluates an expression, given as a virtual string V, in a base environment enriched by
the bindings given by Env, either returning the result X of the evaluation or raising an
exception. Furthermore, the variable KillP is bound to a nullary procedure which,
when applied, interrupts compilation.
virtualStringToValue
{Compiler.virtualStringToValue +V X}
is a replacement for System.virtualStringToValue, which was available in Mozart’s
predecessor DFKI Oz.
Note that you are discouraged from using this for large data structures: Because it
is much more powerful than System.virtualStringToValue, it can also be much
less efficient. Rather, you should use pickling and unpickling of data structures (see
Chapter Persistent Values: Pickle, (System Modules) ).
engine
Compiler.engine
is the final class from which compiler engines can be instantiated. This is described in
detail in Section 4.3.
interface
Compiler.interface
is a class providing a simple mechanism to create compiler interfaces. It is described
in detail in Section 4.4.
parseOzFile
{Compiler.parseOzFile +V +O +P +Dictionary ?T}
parses the Oz source file named V, returning an abstract syntax tree as defined in
Appendix C in T. O is an instance of the PrivateNarrator class described in Ap-
pendix B; its methods are invoked for example to report compilation errors. P is a unary
procedure expecting a switch name as described in Appendix A and returning a boolean
value indicating the switch’s state; in the current implementation, only the settings of
gump, allowdeprecated and showinsert are requested. Finally, Dictionary is
the set of macro names: The keys are defined macro names; its items should always be
true. As a side-effect, Dictionary is modified according to \define and \undef
macro directives.
parseOzVirtualString
{Compiler.parseOzVirtualString +V +O +P +Dictionary ?T}
is similar to parseOzFile, except that V denotes the source text itself instead of a
source file name.
assemble
{Compiler.assemble +Ts +Xs +SwitchR ?P ?V}
4.3. Compiler Engines 9
takes a list of bytecode instructions Ts for the Mozart virtual machine (see Appendix D),
assembles them and returns the result in P, a nullary procedure which causes the code
to be executed when applied. Xs is a list of global variables (the closure of P), the
first element corresponding to register g(0). SwitchR is a record whose features
are switch names and whose values are booleans. In the current implementation, the
switches profile, controlflowinfo, verify, and peephole are used. All features
of SwitchR are optional (default values are substituted). V is a lazily computed vir-
tual string containing an external representation of the assembled code after peephole
optimization.
Instances of the Compiler.engine class are active objects called compiler engines.
Each object’s thread processes all queries inside its query queue sequentially.
The final class Compiler.engine inherits from Narrator.’class’, described in Ap-
pendix B.
enqueue
enqueue(+T ?I <= _)
enqueue(+Ts ?Is <= _)
appends a new query T to the query queue. If T is an unknown query, an exception
is raised immediately. All of the query’s input arguments (the subtrees of T) are type-
checked before it is enqueued.
Internally, each enqueued query is assigned a unique identification number I. This
may be used later to remove the query from the queue (unless its execution has already
begun or terminated).
The argument to enqueue may also be a list of queries: These are guaranteed to be
executed in sequence without other queries interleaving. The second argument then
returns a list of identification numbers.
dequeue
dequeue(+I)
dequeues the query with identification number I, if that query is still waiting in the
query queue for execution, else does nothing.
interrupt
interrupt()
interrupts execution of the current query. Does not affect the remaining queue.
clearQueue
clearQueue()
flushes the whole remaining queue. Does not affect the currently processed query (if
any).
10 Chapter 4. Application Programmer’s Interface
4.3.2 Queries
Macro Definitions
macroDefine(+V)
Add V to the set of defined macro names.
macroUndef(+V)
Remove V from the set of defined macro names.
getDefines(?PrintNames)
Return all currently defined macro names as a list, in no particular order.
Compiler Switches
setSwitch(+SwitchName +B)
Set the state of the given switch to either ‘on’, if B == true, or to ‘off’, if B == false.
getSwitch(+SwitchName ?B)
Return the state of the given switch.
pushSwitches()
Save the current settings of all switches onto the internal switch state stack.
popSwitches()
Restore all switch settings from the topmost element of the internal switch state stack,
provided it is not empty, else do nothing.
Compiler Options
setMaxNumberOfErrors(+I)
Set the maximal number of errors to report for any one compilation before aborting it
to I. A negative value means never to abort.
getMaxNumberOfErrors(?I)
Return the maximal number of errors to report for any one compilation before aborting
it.
4.3. Compiler Engines 11
setBaseURL(+VU)
Set the base URL relative to which the require clause of computed functors is re-
solved. A value of unit means to resolve the imports relative to the location of the file
in which the functor keyword appeared.
getBaseURL(?AU)
Return the base URL relative to which the require clause of computed functors is
resolved.
setGumpDirectory(+VU)
Set the directory in which Gump output files are created. Can be relative. unit means
the current working directory.
getGumpDirectory(?VU)
Return the directory in which Gump output files are created.
The Environment
addToEnv(+PrintName X)
Add a binding for a variable with the given print name, and bound to X, to the environ-
ment.
lookupInEnv(+PrintName X)
Look up the binding for the variable with the given print name in the environment and
bind X to its value. If it does not exist, report an error.
removeFromEnv(+PrintName)
Remove the binding for the variable with the given print name from the environment if
it exists.
putEnv(+Env)
Replace the current environment by the one given by Env.
mergeEnv(+Env)
Adjoin Env to the current environment, overwriting already existing bindings.
getEnv(?Env)
Return the current environment.
feedVirtualString(+V)
Evaluate the Oz source code given by the virtual string V.
feedVirtualString(+V +R)
Evaluate the Oz source code given by the virtual string V, returning the resulting value
in R.result (if the expression switch is set and R has the feature result).
12 Chapter 4. Application Programmer’s Interface
feedFile(+V)
Evaluate the Oz source code contained in the file with name V.
feedFile(+V +R)
Evaluate the Oz source code contained in the file with name V, returning the resulting
value in R.result (if the expression switch is set and R has the feature result).
Synchronization
ping(?U)
Bind the variable U to unit on execution of this query. This allows to synchronize on
the work of the compiler, e.g., to be informed when a compilation is finished.
ping(?U X)
Works like the ping(_) query, except gives a value which will reappear in the response
notification sent to interfaces. This allows to identify the ping query with its pong
notification.
Custom Front-Ends
setFrontEnd(+ParseFileP +ParseVirtualStringP)
Replace the front-end used by the compiler by a custom front-end implemented by pro-
cedures ParseFileP and ParseVirtualStringP. These procedures have the
same signature as Compiler.parseOzFile and Compiler.parseOzVirtualString,
documented above. Indeed, these procedures implement the default Oz front-end.
Query Queue
newQuery(I T)
A new query T with identification I has been enqueued.
runQuery(I T)
The query T with identification I is now being executed.
removeQuery(I)
The query with identification I has been removed from the query queue, either because
it finished executing or because it was dequeued by a user program.
4.4. Compiler Interfaces 13
Compiler Activity
busy()
The compiler is currently busy (i.e., executing a query).
idle()
The compiler is currently idle (i.e., waiting for a query to be enqueued).
State Change
switch(SwitchName B)
The given switch has been set to B.
switches(R)
The settings of all switches is transmitted as a record mapping each switch name to its
setting.
maxNumberOfErrors(I)
The maximum number of errors after which to abort compilation has been set to I.
baseURL(AU)
The base URL relative to which the require clause of computed functors is resolved
has been set to AU.
env(Env)
The environment has been set to Env.
Output
info(V)
An information message V is to be printed out.
info(V Coord)
An information message V, related to the source coordinates Coord, is to be printed
out.
message(R Coord)
An error or warning message R, related to the source coordinates Coord, is to be
printed out. R has the standard error message format, described in Chapter Error For-
matting: Error, (System Modules) .
insert(V Coord)
During parsing, the file named V has been read. The corresponding \insert directive
(if any) was at source coordinates Coord.
displaySource(TitleV ExtV V)
A source text V with title TitleV is to be displayed; its format is the one for which
the file extension ExtV is typically used (such as oz or ozm).
14 Chapter 4. Application Programmer’s Interface
attention()
The error output buffer should be raised with the cursor at the current output coordi-
nates (an error message should follow).
Synchronization
pong(X)
This is sent in response to a ping(_) or ping(_ X) query (see Section 4.3). In the
first case, unit is returned in X.
Methods In addition to the standard error listener interface, it supports the following
methods.
sync()
waits until the compiler engine becomes idle.
getInsertedFiles(?Vs)
returns a list of the file names that compilation has caused the inclusion of so far, in
order of appearance.
getSource(?V)
returns the source that has last been displayed by the compiler (typically some inter-
mediate representation), or the empty string if none.
reset()
clears the internal lists of inserted files and the displayed source.
clear()
is the same as reset.
4.5. Examples 15
4.5 Examples
As a first example, here is an application that expects as single argument the name of
an Oz source file. It parses the file, accepting Gump syntax, and displays the parse tree
in the Inspector (or parseError if parsing failed). If there was a parse error, it extracts
an error messages and prints that to standard output.
functor
import
Narrator(’class’)
ErrorListener(’class’)
Application(getArgs)
Compiler(parseOzFile)
Inspector(inspect)
System(printInfo)
define
PrivateNarratorO
NarratorO = {New Narrator.’class’ init(?PrivateNarratorO)}
ListenerO = {New ErrorListener.’class’ init(NarratorO)}
Startup Since we both want to control a compilation (done by a new compiler en-
gine) and to observe the compilation process (to synchronize and to determine whether
it produced errors), we first instantiate both an engine and an interface which we reg-
ister with the engine. A number of queries are enqueued to the engine: We need to set
the environment and appropriate compiler switches for compilation of an expression
and to cause synchronous execution of the compiled program. When we’re done con-
figuring the compiler, we can start compilation of the source proper, expecting a result
to be returned in variable Result.
16 Chapter 4. Application Programmer’s Interface
Killing We then define the Kill procedure. The rest of the observation is performed
in a new thread, because we want to kill the observation as well when Kill is invoked.
Kill will clear any non-processed queries from the queue and interrupt the current
one, then kill the observation thread (unless it had been already dead).
Observing Next we’ll observe the running compiler, and for this we need to make
use of the interface we created earlier. When the compiler becomes idle, we check
whether it has output any error messages, in which case we record the faulty condition,
else we report success. The main thread waits until the condition becomes known and
reacts upon it.
{Compiler.evalExpression VS env() _}
end
18 Chapter 4. Application Programmer’s Interface
A
Compiler Switches
This appendix describes the available boolean switches, giving their name, their default
setting, and their effects on the compilation process if they are set.
Global Configuration
compilerpasses (default: false)
Output tracing information about the different phases the execution of each query pro-
ceeds through.
Warnings
warnredecl (default: false)
Output warnings about redeclarations of top-level variables, either by declare or lo-
cally.
VI. Debugging
Most of these switches are used by the source level debugger, described in “The Mozart
Debugger” .
Note that the following switches severely impact code size and run-time efficiency of
the generated code.
This appendix documents some supporting classes required to observe a running com-
piler. These classes implement a general producer–consumer pattern for the status
of a running computation and the error messages generated by it. They can be used
independently of the compiler (actually, they are also used by the ozdoc tool that
generated this documentation).
A narrator, presented in Section B.1, is a producer of status and error messages. Con-
versely, a Listener, presented in Section B.2, is a consumer of such messages. Each
listener is connected to exactly one narrator; every narrator may have a number of
listeners (you can observe this if you open compiler panels in the Oz Programming
Interface).
Typically, the result (from, say, a compilation) one will want to programmatically
check for is success or failure, and the list of error messages generated. An error
listener provides easy access to precisely that information, and is presented in Sec-
tion B.3.
Methods
init(?PrivateNarratorO)
initializes a narrator that initially has no listeners attached, and returns the correspond-
ing private narrator.
register(+Port)
registers a new listener Port. All subsequently told messages will be forwarded to Port.
24 Appendix B. Narrators and Listeners
newListener(+Port)
is invoked on every new listener Port that is registered. The default action is a no-op;
subclasses may override this for example to provide the new Listener with a summary
of the current state (as a batch of messages).
unregister(+Port)
unregisters a listener Port. No more messages will subsequently be forwarded to Port.
tell(X)
broadcasts the message X to all registered listeners.
Private Narrators
Methods
setLogPhases(+B)
determines whether messages about phases of the underlying computations should be
broadcasted to listeners (if B is true) or not (if B is false). The default is false.
setMaxNumberOfErrors(+I)
sets the number of error messages to report before interrupting the underlying compu-
tation with a tooManyErrors exception. The default is 17. If I is less than or equal to
zero, infinitely many errors are acceptable.
tell(X)
broadcasts the message X to all registered listeners.
startBatch()
resets internal state (in particular, the error count).
startPhase(+V)
broadcasts an info(...) message to all registered listeners, to the effect that phase V
has started.
startSubPhase(+V)
broadcasts an info(...) message to all registered listeners, to the effect that sub-
phase V has started.
endBatch(+A)
broadcasts messages to all registered listeners about the outcome of the underlying
computation. A can be one of accepted, rejected, aborted, crashed, or interrupted.
For any but accepted or interrupted, an attention message is broadcast. Causes
an info(...) message to be broadcast.
error(coord: +Coord <= unit kind: +KindV <= unit msg: +MsgV <= unit
warn(coord: +Coord <= unit kind: +KindV <= unit msg: +MsgV <= unit item
hasSeenError(?B)
returns true iff an error message has been broadcast.
Methods
init(+NarratorO +ServeL)
initializes a listener with a narrator and the label of a unary method. The listener creates
a port, registers this with NarratorO, and creates a thread in which the ServeL
method is applied to the port’s stream.
close()
undoes all effects of the init method: The server thread is terminated and the listener’s
port is unregistered.
getNarrator(?NarratorO)
returns the narrator with which the listener’s port is currently registered.
getPort(?Port)
returns the associated port.
Methods
reset()
is a no-op, intended to be overriden by derived classes. Invoked when a close()
message is received.
26 Appendix B. Narrators and Listeners
setVerbosity(+L)
sets the verbosity to L, which can be one of true (print all received messages to stan-
dard error), false (print none of the messages), and auto (print all messages if some
error message is among them).
hasErrors(?B)
returns true iff some error message was received since the last close() message.
isActive(?B)
returns true iff some error or warning message has been received since the last close()
message.
getVS(?V)
returns the history of messages as a virtual string.
getMessages(?Xs)
returns the history of messages as a list.
formatMessages(+Xs ?V)
takes a list of messages Xs and returns them as a virtual string.
C
This appendix documents the syntax tree data structure used by the compiler. This
information is only needed by implementors of custom front-ends. Most nodes are
self-explanatory; if in doubt, it is recommended that you refer to the Gump sample
implementing an Oz parser (installed at examples/gump/OzParser.ozg).
Input
Compilation Units
Phrases At the syntactical level, statements are not distinguished from expressions.
Both are subsumed by hphrasei. In a top-down analysis of the tree, it can be deter-
mined which phrases need to be statements and which need to be expressions. The
fStepPoint form is only required if you want to provide support for source-level de-
bugging: It wraps the contained phrase into a step point (see “The Mozart Debugger” );
the atom can be freely chosen to indicate its kind (call, conditional, etc.).
28 Appendix C. Syntax Tree Format
Procedures can carry flags (atoms following the proc or fun keyword). For the mo-
ment, the only recognized flags are instantiate (the body’s code is copied upon
application), lazy (the body has by-need semantics), dynamic (disable static-call op-
timization of this procedure), and sited (cannot be pickled). Other atoms are silently
ignored.
Functors
Classes
Features
Other
Coordinates Each triple consisting of an hatomi and two hintis denotes a file name
(” if none known), a line number (starting at 1; required) and a column number (start-
ing at 0; ~1 if none known). If two triples are given, then they denote the starting
and ending coordinates of a construct. A pos may be turned into a fineStep or a
coarseStep, denoting a step point for debugging. unit is an unknown coordinate.
hphrasei += fScanner(hvariablei
[hclass descriptori] [hmethi]
[hscanner rulei] hatomi hcoordi)
| fParser(hvariablei
[hclass descriptori] [hmethi]
htoken clausei [hparser descriptori] hinti
hcoordi)
Scanners
Parsers
CompilerPanel
’class’
CompilerPanel, ’class’, addAc-
tion, 6
CompilerPanel, ’class’, close, 6
CompilerPanel, ’class’, enqueue,
6
CompilerPanel, ’class’, init, 6
36