Alpha_1 Programmers's Manual

C_shape_edit Programmer's Overview

This document serves as an overview for programmers of the major components of the c_shape_edit program and libraries. Throughout this document, class and function names will be used. It is suggested that readers use the Alpha_1 "tags" facility within emacs to look up the source code documentation for detailed information.

Two other documents are available that detail procedures for c_shape_edit development. There is the C_shape_edit Programmer's Guide for information about writing applications using the c_shape_edit libraries, and there is the C_shape_edit Developer's Guide for information about extending and modifying c_shape_edit.

Functional Overview

C_shape_edit is a program combining the features of a number of object classes described below. The components of c_shape_edit are all available through software libraries so any Alpha_1 program can contain the functionality of c_shape_edit or subsets thereof. The major function is to provide model construction, dependency maintenance, and related services through a number of interfaces.

Interfaces

There are two main interfaces: 1) an interpreted, command language interface and 2) an object-oriented programming interface. The programming interface also has an optional remote procedure call interface for using multiple processes. Either interface can be used as a foundation for a graphical interface.

Class Overview

The following is a brief description of the main classes that are used.

model_obj

The model_obj class can really be thought of as a "package" or a "module." This is the central class used to implement c_shape_edit and ties together the functionality of a number of other classes (see below).

Objects in this class represent nodes in a dependency graph. The main contents of a model_obj are the "cons_fn," the function used to construct the object, the "prereqs," the prerequisite objects (the arguments to the constructor function), the "param," the resulting geometric object (a cache), and the "dependents," the model_obj's that depend on the given object as their prerequisites.

In addition to the methods for model construction and maintenance regarding dependency graphs, there are a number of static members (methods and data members) used to store state, provide various side effects, and wrap interfaces to other classes. These other classes provide specialized services (see below).

model_list_obj

A shared list of model_obj's. A model_list_obj is used for the "dependents" of a model_obj.

mi_type

The mi_type class provides the remote procedure call interface for a client process. This is basically a remote interface to the model_obj model construction and dependecy maintenance methods. A global instance of the class named mi is defined in libMI.

client_type

The client_type class implements the low-level client-side communications for remote procedure call applications.

model_server_type

The model_server_type class implements the server-side of the network interface for remote procedure call applications. A global instance of the class named ms is defined in libMI.

Model Interface Protocol objects.

The following objects are the low-level objects that implement the Model Interface Communication Protocol for remote procedure call.

construct_obj
download_obj
query_obj
eval_code_obj
replace_obj
drop_server_obj
select_events_obj
reply_obj
error_obj
event_obj

Argument List Classes

There are a number of classes for representing argument lists for various purposes. Generally speaking, these lists are heterogeneous lists (possibly nested) which can contain the fundamental types (int, real_type, string_type) plus object references of some kind. Each particular class has a specific set of types that are valid. These types are specified by a type tag from an enumeration, arg_type, common to all the argument list classes. Individual classes restrict the type tags by the set of constructors that is provided. The current full set of types is:

A_ID - A model ID (id_type).
A_INT - An integer.
A_FLOAT - A real_type.
A_STRING - A string_type.
A_LIST - A nested list.
A_SYM - A symbolic name.
A_OBJ - A general object_type pointer.
A_MODEL - A model_obj pointer.

Here are descriptions of the argument list classes:

arg_obj: Argument list "item" for remote procedure call client/server communication. An arg_obj can represent the basic data types (int, float, string), symbolic ID's, model ID's (id_type), and nested lists. Symbolic ID's (A_SYM) and nested lists (A_LIST) are for RLISP shape_edit ONLY.
sym_exp_obj: A symbolic code expression for lisp-like representation of expressions in a functional language. Used in the parser and interpreter for SCL (c_shape_edit). An item in a sym_exp_obj list can represent the basic data types (int, float, string), symbolic names (variable and function names), and nested sub-expressions (lists).
value_obj: The result of evaluating a sym_exp_obj (symbolic expression). This is a base class (platform) for prereq_obj and ptr_val_obj. Value_obj's are accumulated into arguement lists for model_obj constructor functions or general purpose side-effect function calls in the interpreter. This is the return type for the model_obj "eval" methods and for side-effect functions. The set of valid type tags is the union of the derived class type tags (see below).
Value_obj is also used as a special case "value" for model_obj (model_obj::param()) to represent the basic data types (numbers and strings). (For example: x = 1.2; in SCL.)
prereq_obj: Item in a model_obj prerequisite (argument) list. Derived from the value_obj class. Represents basic data types (int, float, string) plus shared model_obj pointers.
ptr_val_obj: A wrapper class for holding a general object_type pointer. Derived from the value_obj class. ptr_val_objs's are used as the return value for side-effect functions that return shared or non-shared general (i.e.: not model_obj's) object pointers. They are also used for constructors or side-effect functions that return arrays. (See array_val_obj.)
array_val_obj: A container class for a list of value_obj's. This is used as a special case "value" for a model_obj (model_obj::param()) which represents a general array ({} syntax in SCL). SCL arrays are heterogeneous arrays of int, float, string, general object_type pointers, or model_obj pointers.

Source Directory Information

The above classes are implemented in two libraries refered to as the model library, or libModel, and the model interface library, or libMI. The Alpha_1 shell variables $a$molib and $a$milib refer to the library directories and $a$aimo and $a$aimi refer to the include directories.

C_shape_edit Main Program

The c_shape_edit program is a simple wrapper on the model_obj and model_server_type classes. The main program initializes the network server and the interpreter symbol table and then processes input from stdin via the interpreter. The output of the interpreter is written to stdout. C_shape_edit can be run from a UNIX shell or under emacs with Alpha_1 "SCL-mode" support. The main program is found in the $a$modeld directory.

Alpha_1 Programmer's Manual Home Page

alpha1@gr.utah.edu