2 The Interactive Development Environment

Denys Duchier and Andreas Sundström

This tutorial contains many code examples and you are highly encouraged to try them out interactively as you go. This can be done very comfortably by taking advantage of the Mozart system's interactive development environment. We normally call it the OPI, which stands for the Oz Programming Interface, and it is described extensively in ``The Oz Programming Interface''. In the present section, you will learn just enough about the OPI to allow you to start experimenting with our code examples.

2.1 Starting The OPI

Under Unix, the OPI is normally started by invoking the command oz at the shell prompt. Under Windows, the installation procedure will have provided you with a Mozart system program group: click on the Mozart item in this group. Shortly thereafter you get a window that looks like this:

The OPI uses the Emacs editor as the programming front-end. If you are not familiar with Emacs or its terminology, you should consult the Emacs on-line tutorial [Sta91] available from the Help menu in the Emacs menu bar.

The initial window is split in two text buffers. The upper buffer called Oz is a space where you can write small pieces of code and interactively execute them: it essentially plays, for Oz code, the same role as the *scratch* buffer for emacs lisp code. The lower text buffer is called *Oz Compiler* and shows a transcript of your interaction with the compiler of the Mozart subprocess.

2.2 Hello World

Let us begin with the traditional Hello World example. In the Oz buffer, type the following:

{Show 'Hello World'}

This example illustrates the unconventional syntax of procedure invocation in Oz: it is indicated by curly braces. Here, procedure Show is invoked with, as single argument, the atom 'Hello World'.

In order to execute this fragment, we position the point on the line we just typed and select Feed Line from the Oz menu in the menubar. We now see:

The transcript from the compiler indicates that {Show 'Hello World'} was fed to the compiler and accepted, i. e. successfully parsed and compiled. But was it executed, and, if yes, where is the output? Indeed it was executed, but the output appears in a different buffer called *Oz Emulator*: this contains the execution transcript. If we select from the Oz menu Show/Hide -> Emulator, we now see:

2.3 Good News For The Programmer

The OPI has many features to support interactive code development.

2.3.1 Code Editing

The oz-mode is a major mode for editing Oz code, and provides automatic indentation as well font-lock support for code colorization.

2.3.2 Key Bindings

You may interact with the underlying Mozart subprocess from any buffer in oz-mode, not just from the Oz buffer as demonstrated earlier. Furthermore, all the actions that we carried out in the Hello World example can be invoked more conveniently through key bindings instead of through the Oz menu.

a ``paragraph'' is a region of text delimited by empty lines.

2.3.3 Compiler Errors

The OPI also has support for conveniently dealing with errors reported by the compiler. Let us type the following erroneous code in the Oz buffer:

local A B in 
   A = 3
   proc {B}
      {Show A + 'Tinman'}
   end 
   {B 7}
end

and feed it to the compiler using M-C-x. The compiler reports 2 errors and we see:

C-x ` (that is Control-x backquote) positions the transcript to make the first error message visible and moves the point, in the source buffer, to where the bug is likely to be located.

Indeed, we should not try to add an integer and an atom! If we invoke C-x ` once more, we see:

Here, we have mistakenly applied a nullary procedure to an argument.

2.3.4 Graphical Development Tools

The mozart system has many graphical tools. Here we only mention the Browser which is otherwise extensively documented in ``The Oz Browser''. So far, we merely used the procedure Show to print out values. Instead, we can invoke Browse to get a graphical display interface. For example, feeding:

{Browse 'Hello World'}

causes the following new window to pop up:

This is not very exciting, but let's now feed this code:

declare W H
{Browse foo(width:W height:H surface:thread W*H end)}

Now the browser window shows a term that is only partially known (instantiated) since variable W and H have been declared but not yet bound to values:

Now let us feed W=3 and we see that the browser automatically updates the display to reflect the information we just added.

Now we feed H=5 and again the browser updates the display and now shows a fully instantiated term:

The browser allows you to see the evolution of the instantiation of a term as concurrent computations (threads) proceed and add more information.