Agora94 User Guide

Koen De Hondt
Last revision: August 7th, 1996

Agora94 User Guide - Running an Agora Program

This chapter describes what steps to take to execute Agora programs.

An Agora program is always a block. It is to be considered a block that is executed as a mixin method on the root object. It may thus not contain a return statement. The result of the evaluation of an Agora program is an error or the (possibly extended) root object.

Before a program is evaluated its source text is parsed, and checked for static semantic errors. If no errors of any kind are found, the program is evaluated. Depending on the evaluation command given, the evaluation result is ignored or inpected by means of the Agora object inspector (see the following chapter).

Evaluation commands

An arbitrary Agora expression is evaluated when a Do It or Inspect It command is given in an Agora text editor window. With Do It All and Inspect It All the whole contents of a text editor window is evaluated. Do It All and Inspect It All are used most frequently.

Steps taken by the system before evaluation

Two steps are taken before a program can actually be evaluated: a parse step and a check step.


The parser checks the program text for grammatical errors. The parser stops as soon as it has encountered an error. The offending identifier or symbol is selected in the text editor and a dialog explaining the error is raised.

Figure 10: Parser error dialog


The checker looks for static semantic errors in the program. It collects all errors at once. The characters in the erroneous text parts are changed to white to clearly mark them and a dialog is put on the screen.

Figure 11: Checker error dialog

There exist two categories of checker errors. The first category is made up of the real semantic errors: they prevent evaluation. The second category is made up of the warnings: they do not prevent evaluation to take place, but they have a high probability of generating runtime errors.

When errors are found, different dialogs are used to report on them depending on the presence of only errors, only warnings or errors and warnings. They all share the inspect them button. When this button is clicked the dialog is put away and a checker errors inpector in opened. The user can inspect the errors and warnings that were found in the program. This inspector is handy for Agora novices. More experienced Agora programmers will probably dismiss the checker error dialog by means of the cancel button.

Figure 12: Checker errors inspector


After parsing and checking, the program is evaluated. If no runtime errors occur the system generates a done sound after the program is completely evaluated. Otherwise the program part generating the runtime error is selected in the text editor and a dialog is put on the screen to explain what went wrong.

Figure 13: Runtime error dialog

Inspecting the result of an Agora program

When an Agora program is successfully evaluated with the Inspect It command, an Agora object inspector is opened on the result of the evaluation.

Figure 14 shows an object inspector on the point variable p1 taken from the point example file (points.ago in the examples directory).

The window label ("root + point") is the sequence of mixins-methods that has been applied to the inspected object. In this example p1 is a root object extended with the point mixin-method.

Figure 14: Object Inspector

The object inspector consists of two areas, each subdivided in two. The top area displays the public part and the botton area displays the local part of the inspected object. Each area contains two views: on the left the attributes of the object are listed, on the right the contents of a selected attribute is shown. The lists on the left show all segments of the object. The top segment corresponds with the last applied mixin. The attributes in the list are preceded by the name of the mixin, e.g. -point-, that extended the object with those attributes. Attributes can be inspected by selecting them and choosing Inspect from the <operate> menu of the list views.

In this example tree x entries are listed in the public part, since x is declared as a public local variable (hence the x and x:) and as a cloning functional method (hence the second x:).