Assignment IV

Due date : Tuesday October 30, 2001




The purpose of this assignment is to extend the Geometry packages of the
previous assignment, to write a simple interpreter to support interactive
use, and to understand basic notions of information hiding.

I) The interpreter takes commands from the user to define geometric shapes
and display them. A command creates a new object or manipulates existing
objects. When objects are introduced into the system they are given a name,
and they can be refered to by their name in subsequent commands. Command
syntax is as follows (terminal symbols are in lower-case):

           Command         => Build_Command; | Display_Command;
           Build_Command   => Build_Simple | Build_Figure
           Build_Simple    => Build_Kind id Coordinate_List
           Build_Figure    => figure Id_List
           Display_Command => display id
           Build_Kind      => point | line | square 
           Coordinate_List => int | int Coordinate_list
           Id_List         => id | id Id_List

For example:
              point center 10 10;
              point diag1  15 15;
              square s1    0 0 20 20;
              figure doodle s1 center;
              display   s1;
              display   doodle;

No need for any complex parsing approach: the first token is an identifier
that specifies the command. Commands are terminated by a semicolon, so the
list of arguments can be given over several lines. The structure of the
interpreter is of course a case statement: read the first token and call
the routine that handles that particular command.

We need a data structure (a symbol table) to associate the names with the
figures. No need for anything complex: a list will do. Each element of the
list is a pair (name, object). To retrieve the object associated with a name,
do a sequential search over the list. The list handling should be in its own
package, of course.

II) Information hiding means that the structure of geometric figures should
be available only through a limited interface: the user should not modify
the coordinates of a given figure by a direct assignment, but only through
a well-defined set of procedures. For example, the type Point should be
declared as a private type, with operations X_Coord and Y_Coord.  To build
a point you can declare either a procedure:

         type coordinate is range 0 .. 100;
         procedure New_Point (P : in out Point; X, Y : Coordinate);

or a function

         function New_Point (X, Y : Coordinate) return Point;

and so on for the other figures. For squares, similarly, you can define
functions that yield the coordinates of any corner. Some of these may be
stored directly in the data structure, the other might be computed, but
the user sees the same interface:

        function Lower_left_X  (S : Square) return Coordinate;
        function Upper_Right_Y (S : Square) return COordinate;

and so on. Feel free to use other names, of course.

An example of a procedure that modifies an existing figure is:

        procedure Translate (P : in out Point; dX, dY : Coordinate);

you can imagine defining such procedures for other elementary figures as
well as for composite figures (this is not required for this assignment).


III) Error recovery: don't spend too much time making the input routines
completely robust. You can use exceptions to handle Data_Error if you
want, and query the user again if the input is malformed, but this is
optional.