GRAPPLE(ID:329/gra022)


GRAPh Processing LanguagE. 1968.


Structures:
References:
  • Tesler, L.G. et al, "A Directed Graph Representation for Computer Simulation of Belief Systems", pp19-40 view details
          in Math Biosciences 2 (1968). view details
  • Weinzapfel, Guy; Johnson, Timothy E.; Perkins, John "IMAGE: An interactive computer system for multi-constrained spatial synthesis" p.101-108 view details Abstract: IMAGE is a system of computer programs which generates three dimensional spatial arrangements to satisfy spatial requirements specified by a designer. A problem specification is composed of two elements: geometric descriptions of the spaces to be configured; and relationships between those spaces which the designer wishes to achieve. Given a problem description, IMAGE generates arrangements until a configuration is achieved which satisfies all specified relationships. If no such configuration is possible, IMAGE produces arrangements which minimize dissatification of the specified relationships. IMAGE, the computer design aid system described in this paper, has been developed to go beyond the single parameter approach, to operate on a more flexible set of form explicit criteria and to facilitate its interaction with the designer's own process. Extract: INTRODUCTION
    INTRODUCTION
    During the early phases of computer aided design research, problems of spatial arrangement enjoyed a somewhat misleading popularity.
    This popularity was founded on the acceptance of single, easily quantified parameters as adequate representations of the problem;
    numerous programs were developed to give "optimal" arrangements of blocks on the simple basis of weighted adjacencies or similar distance functions. More complex spatial relationships, such as circulation and visual access, had to be modeled indirectly by the distance parameter. And form criteria, such as size and shape, could not be addressed as variables at all. These programs were an important initial step, but because of their reliance on simple parameters they failed to adequately address the process they were created to assist.
    IMAGE, the computer design aid system described in this paper, has been developed to go beyond the single parameter approach, to operate on a more flexible set of form explicit criteria and to facilitate its interaction with the designer's own process.
    Extract: THE CONTEXT FOR A DESIGN AID
    THE CONTEXT FOR A DESIGN AID
    The primary factor of the designer's search for a satisfactory form is his image, or perception, of a problem. It is this image which motivates the generation, transformation, selection, or rejection of various form alternatives.
    A designer's image of his problem derives from diverse sources which go well beyond the objectives stated by and inferred from his client. This image is affected by his commitments to a larger audience than his immediate client, is impacted by his experience as a designer, and is based in the culture and political system of which he is a product. Though only a few of the factors which affect the designer can actually be traced to their sources, and though their effect on his search for form is often immeasurable, they do combine to form a very rich and diverse problem image.
    The designer's problem image is also dynamic. It changes as his client's objectives become more specific. It is altered by his search for solutions and changes at the pace of an advancing culture and technology, as well as at the pace of the problem's development.
    The interface between the designer's perception of his problem and its ultimate solution can be characterized by the translation of the problem's various objectives into explicit form requirements.
    For example, the need for acoustic privacy between two spaces can be translated into several different form criteria. The two rooms might be separated by dense walls, by large distances or even by other spaces. Each of these interpretations will have different form consequences. The selection of any particular form specification is a significant commitment towards a final form.
    In the process of seeking a form solution, the designer may explore the consequences of several different interpretations for a single objective. In such a case, he seeks not only the solution to his problem but a satisfactory description of that problem as well.
    Of course, not all of the designer's perceptions need to be translated into specific form criteria. It is probably impossible for the designer to account for his total wealth of problem information; and many of his objectives will not even relate directly to form. Moreover, each particular form directive will probably be influenced by several interdependent factors of the designer's problem image.
    It is the designer's particular strategy, then, to employ as much or as little of his perception as he feels necessary to initiate his search for a form -- to operate heuristically, exploring different formulations of his goals and to hypothesize a large variety of form solutions.
    The major objective of the IMAGE system is to assist the designer in his search for an appropriate description of his problem, and to aid in the creation of spatial arrangements which satisfy that description. To do this, IMAGE provides the designer with a language of form-explicit relationships.
    These relationships are used to translate the designer's objectives into a form directive model from which alternate spatial arrangements can be generated. In turn, the spatial arrangements generated to satisfy this model enable the designer to see the consequences of a particular form interpretation and to explore the effects of different problem formulations.
    In this way, IMAGE aids the designer in his search for both the problem statement and the problem solution. Extract: THE IMAGE SYSTEM
    THE IMAGE SYSTEM
    PROBLEM SPECIFICATION
    The designer initiates his use of IMAGE by constructing a model or form specific description of his problem. This problem description consists of both the spaces to be arranged and of the form relationships which should be satisfied between those spaces. With such a problem description, IMAGE can generate alternative spatial arrangements.
    SPACES
    Each space which the designer specifies in IMAGE is a rectangular volume defined by nine variable descriptors. These nine descriptors contain the data necessary to describe the position, size, and orientation of the rectangular volume in Euclidean space. Three of the nine variables contain the x, y, and z coordinates at the centroid of the space. Three others contain the dimensions of the space, measured from its centroid to its outer faces. The final three variables are used to record the space's orientation. With these descriptors, any plane, corner, or edge of a volume can be located in three dimensions by simple calculations. Changes in any of its descriptors represent physical change to the space, and it is by manipulating the values of these spatial descriptors that IMAGE generates new configurations. Rectangular volumes were chosen to minimize computation complexity yet provide the ability to study problems in three dimensions. The choice of non-rectangular spaces would have greatly complicated the generating routines, extended computer usage time, and enlarged the data storage requirements.
    NON-RECTANGULAR SPACES
    Of course, not all architectural spaces are rectangular. Many functions require more complex forms. For example, auditoriums, operating theatres, and sports arenas require angular or curved surfaces. Despite its limitation to rectangular volumes, however, IMAGE does allow a designer to deal with more complex forms by aggregating several volumes into one. Two or more rectangular spaces may be combined to form a composite volume whose outer surface forms the required shape and whose constituent volumes act as a single unit. The composite volume gives the designer an opportunity to develop a more elaborate and explicit specification of his problem. For example, a designer may have a specially shaped:space in mind for the performance area of a theatre. He can create the form of that space using several rectangular volumes fixed relative to one another in a desired configuration (See Fig. l ) . He then has the opportunity to specify special relationships between individual components of the space and other parts of the building.

          in [ACM/IEEE] Annual ACM IEEE Design Automation Conference Proceedings of the June 1971 design automation workshop on Design automation, Atlantic City, New Jersey, United States view details
  • Williams, D. L., "GRAPPLE - Graphics Application Programming Language". NRC 3rd Man-Computer Communications Seminar, May, 1973. view details
          in [ACM/IEEE] Annual ACM IEEE Design Automation Conference Proceedings of the June 1971 design automation workshop on Design automation, Atlantic City, New Jersey, United States view details
  • O'Brien, C. D.; and Bown, H. G. "IMAGE: a language for the interactive manipulation of a graphics environment" p53-60 view details Extract: Introduction
    INTRODUCTION
    An interactive computer graphic system is a system which permits a 'conversation' to occur between the user and the computer, where the communications medium is a computer driven display. The complexities of the interactive dialogue, which result from the use of an interactive computer graphics system create complex programming problems. Conventional programming languages are executed serially, instruction by instruction, with the execution flow controlled by conditional statements. Although it is possible to write a graphics application program in this serial fashion it can be quite awkward to do so. The highly interactive nature of a graphics program lends itself to programming in an action oriented language. In this paper the design of a new interactive graphics language 'IMAGE' is presented. This language places particular emphasis on providing a graphics applications programmer the ability to easily program graphical interaction.
    From an examination of programs written in a variety of languages it was concluded that the writing of interactive graphical application programs is greatly aided when the following five facilities are available.
    a) Graphical input response facilities
    b) Graphical drawing facilities
    c) Structured programming constructs
    d) Data manipulation facilities
    e) Easy access to external software

    Graphical Input Response Facilities


    One of the main requirements of any interactive process is to define the response of the system to each input. One approach which has been suggested by Newman is that this system should be considered as a finite state automaton where an 'action' is simply an input to the system and the corresponding 'reaction' is determined by the state of the system at the time. This approach to defining a program control sequence can be implemented such that the programmer is required to be specifically aware of all the states of his system in order to specify the action-reaction sequences, or the system can be designed such that these state transitions are transparent to the programmer. DIAL is an example of the former system, whereas ICPL is an example of the latter. Because it puts less of a burden on the programmer, it is felt that the latter method is superior. Most languages provide only highly device dependent information about particular inputs. This device dependence can be removed by providing suitable language constructs referencing a small number of idealized devices.

    Graphical Drawing Facilities


    There are two common ways of providing graphical drawing facilities needed in a general purpose interactive graphical programming system. The first involves the notion of function or subroutine calls and does not require any modification to the base language from which they are called. Many graphic systems available today (especially those supplied by manufacturers) are of this type. Specific examples are GINO and GRAF. Graphical drawing facilities may also be provided by specific instructions within the language. This provides the capability of defining display procedures. This method , however, requires modification of the syntax of the base language or the creation of a complete new language. Display procedures provide distinct items on which to apply transformations, and therefore provide a compact, high-level method of defining pictures. EULER/G and GRAPPLE are examples of language systems providing this display procedure capability.

    Structured Programming Constructs


    It is very important that the base language provide good facilities for defining the overall structure of the program. Examples of languages exhibiting excellent program structure facilities are ALGOL and to a lesser extent, IFTRAN. Both these languages provide good constructs for iterative and conditional operations such as IF, WHILE and ELSE. A local subroutine capability is desirable, and provides a convienent method of implementing a display procedure capability.

    Data Manipulation Facilities


    A computer graphics program describes pictures in a numerical form and textual information in terms of character strings and it is therefore useful to have both numerical and character data types. In certain applications it is essential that a representation of a picture be stored in a dynamic data structure, thus providing the capability of manipulating and regenerating it. It may overburden the syntax of a graphics language to provide a generalized data structure capability, so, as a minimum, access to external facilities written in other languages should be provided.

    Easy Access to External Software


    Any good programming'system should provide an easy and convenient access to external software packages. Very often an application program will require access to some external routines that are already provided in the computer system library or that already exist written in some other language like FORTRAN or ALGOL. The communication of data to external software should be in a simple manner, such as direct narameter references. We do not feel that these requirements are adequately met in any existing language. The 'IMAGE' language was designed to specifically satisfy the above criteria. A unique interaction control structure, along with a display procedure based picture description grammar and device independent interaction input facilities were combined to form 'IMAGE'. The remainder of this paper will present a brief description of the syntax of 'IMAGE'.
    Abstract: This paper addresses itself to the problems involved in programming an
    interactive computer graphics display. A list of graphical programming facilities considered necessary for an interactive
    graphic programming language is presented. An examination of several application programs, written in a variety of existing languages, revealed that many of these facilities are usually lacking.

    This paper presents the design of a new interactive graphics language 'IMAGE', developed specifically to satisfy the above criteria. The language places particular emphasis on providing a graphics application programmer the ability to program graphical interaction. The 'IMAGE' language utilizes the better features of several current graphic languages and combines these features with a unique interaction control structure. This OBJECT / ACTION control structure, the display picture description syntax and the hardware independent handling of input devices are the main features of the language, providing excellent graphical input response and drawing facilities. The device independent input / output structure permits the implementation of a portable language syntax, since there are no references to display hardware devices. All display references are performed through a virtual terminal. This paper contains a detailed description of the main features of the language and these features are illustrated in an example 'IMAGE' program. Extract: Introduction
    Introduction
    An interactive computer graphic system is a system which permits a 'conversation' to occur between the user and the computer, where the communications medium is a computer driven display. The complexities of the interactive dialogue, which result from the use of an interactive computer graphics system create complex programming problems. Conventional programming languages are executed serially, instruction by instruction, with the execution flow controlled by conditional statements. Although it is possible to write a graphics application program in this serial fashion it can be quite awkward to do so. The highly interactive nature of a graphics program lends itself to programming in an action oriented language.
    In this paper the design of a new interactive graphics language 'IMAGE' is presented. This language places particular emphasis on providing a graphics applications programmer the ability to easily program graphical interaction.
    From an examination of programs written in a variety of languages [1] it was concluded that the writing of interactive graphical application programs is greatly aided when the following five facilities are available.
    a) Graphical input response facilities
    b) Graphical drawing facilities
    c) Structured programming constructs
    d) Data manipulation facilities
    e) Easy access to external software

    a) Graphical Input Response Facilities: One of the main requirements of any interactive process is to define the response of the system to each input. One approach which has been suggested by Newman [2] is that this system should be considered as a finite state automaton where an 'action' is simply an input to the system and the corresponding 'reaction' is determined by the state of the system at the time. This approach to defining a program control sequence can be implemented such that the programmer is required to be specifically aware of all the states of his system in order to specify the action-reaction sequences, or the system can be designed such that these state transitions are transparent to the programmer. DIAL [41 is an example of the former system, whereas ICPL [3] is an example of the latter. Because it puts less of a burden on the programmer, it is felt that the latter method is superior. Most languages provide only highly device dependent information about particular inputs. This device dependence can be removed by providing suitable language constructs referencing a small number of idealized devices [5].

    b) Graphical Drawing Facilities: There are two common ways of providing graphical drawing facilities needed in a general purpose interactive graphical programming system. The first involves the notion of function or subroutine calls and does not require any modification to the base language from which they are called. Many graphic systems available today (especially those supplied by manufacturers) are of this type. Specific examples are GINO [6] and GRAF [7]. Graphical drawing facilities may also be provided by specific instructions within the language. This provides the capability of defining display procedures [8]. This method , however, requires modification of the syntax of the base language or the creation of a complete new language. Display procedures provide distinct items on which to apply transformations, and therefore provide a compact, high-level method of defining pictures. EULER/G [9] and GRAPPLE [101 are examples of language systems providing this display procedure capability.

    c) Structured Programming Constructs: It is very important that the base language provide good facilities for defining the overall structure of the program. Examples of languages exhibiting excellent program structure facilities are ALGOL [11] and to a lesser extent, IFTRAN [12,13]. Both these languages provide good constructs for iterative and conditional operations such as IF, WHILE and ELSE. A local subroutine capability is desirable, and provides a convienent method of implementing a display procedure capability.

    d) Data Manipulation Facilities: A computer graphics program describes pictures in a numerical form and textual information in terms of character strings and it is therefore useful to have both numerical and character data types. In certain applications it is essential that a representation of a picture be stored in a dynamic data structure, thus providing the capability of manipulating and regenerating it. It may overburden the syntax of a graphics language to provide a generalized data structure capability, so, as a minimum, access to external facilities written in other languages should be provided.

    e) Easy Access to External Software: Any good programming'system should provide an easy and convenient access to external software packages. Very often an application program will require access to some external routines that are already provided in the computer system library or that already exist written in some other language like FORTRAN or ALGOL. The communication of data to external software should be in a simple manner, such as direct narameter references. We do not feel that these requirements are adequately met in any existing language. The 'IMAGE' language was designed to specifically satisfy the above criteria. A unique interaction control structure, along with a display procedure based picture description grammar and device independent interaction input facilities were combined to form 'IMAGE'. The remainder of this paper will present a brief description of the syntax of 'IMAGE'. Extract: The 'IMAGE' Language
    The 'IMAGE' Language
    'IMAGE' has been designed in order to provide a language in which a relatively untrained person can program interactive graphic application programs. The language is designed for 'application programmers'; that is, persons who have some knowlege of programming but have most of their expertise in the field of their application. The language provides a basic set of graphical drawing commands and augments this with a powerful set of display modifiers. The language is procedure oriented and procedures may be easily defined within a program.
    An easy method has been provided to communicate with external programs written in other languages, so that an applications programmer can write sections of his program package in languages more suited to other tasks such as data manipulation or complex calculations. This feature has the virtue of easily allowing the programmer to add a graphics capability to an already existing applications package written in some other language. This permits the major emphasis of the syntax of this language to be for picture description and interaction control.
    The form of the execution flow control statements borrows from the format of the 'IFTRAN' FORTRAN preprocessor (Bezanson [13], Miller [12,14]) in order to provide a structured programming capability. The adoption of a simple data formatting scheme and the use of character string variables has allowed for the design of a language structure which uses no labels at all.
    This language has been designed so that it addresses the graphical problem directly in a hardware independent manner. A program written in this language should onerate regardless of which I/O devices are available. Device independence has been designed into the language so that particular device technologies have a minimum effect on the programs written in the language. For example, a program which uses a light-pen as an identifier on one system should operate just as well using a trackball and a cursor on another. The language treats all displays as identical and allows similar operations to occur on them. The programmer introduces device dependency only when he depends on the speed of a particular implementation. The myriad of input devices have been broken into six classes. Three of these classes are particularly concerned with interaction with the display. The other classes of interaction are general in nature and could be associated with a non-graphical program.
    Interaction control commands allow these graphical devices to be assigned to particular input functions. Each device behaves as a virtual device so that it is possible to use software techniques to allow one real device to perform the function of another. For example a positioning device such as a track-ball can be used to identify light-buttons, even though the concept of a light-button was derived from light-pen usage.
          in Computer Graphics 9(1) Spring, 1975 - includes Proceedings of the 2nd International Conference on Computer Graphics and Interactive Techniques, 1975, Bowling Green, Ohio view details