GRAF(ID:288/gra004)GRaphic Additions to FORTRANfor GRaphic Additions to FORTRAN. FORTRAN plus graphic data types Related languages
References: GRAF: GRAPHIC ADDITIONS TO FORTRAN A. HURWITZ J.P. CITRON IBM Los Angeles Scientific Center J.B. YEATON Health Science Computing Facility UCLA Los Angeles, California With growing widespread use of graphic display devices, an easy-to-use high-level graphic display language has become a necessity. GRAF is intended to fill a gap between the two extremes of a package of subroutines in FORTRAN as opposed to custom-designed single-use graphical display programming systems. In GRAF, new statements are added to the FORTRAN language. GRAF will be easier to implement, easier to teach to FORTRAN programmers, and easier to read. It was designed to extend OS/360 FORTRAN IV (E Level subset) and to operate with the IBM 2250 Mod display device. in [AFIPS] Proceedings of the 1967 Spring Joint Computer Conference, April 18-20, Atlantic City, N. J. SJCC 30 view details in [AFIPS] Proceedings of the 1967 Spring Joint Computer Conference, April 18-20, Atlantic City, N. J. SJCC 30 view details Hurwitz et al. (1967)--describes GRAF (GRaphic Additions to Fortran), a language which is Fortran plus some added statements to facilitate graphics programming. GRAF was written at IBM Los Angeles Scientific Center and the Health Sciences Computing Facilities, UCLA, to extend OS/360 Fortran IV (E level) and .to operate with the IBM 2250 I. The programs described by Dixon (1967) were implemented using GRAF in [ACM] ACM Computing Surveys 2(4) Dec1970 view details 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 in Computers & Automation 21(6B), 30 Aug 1972 view details The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one. There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages. The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM. Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) . It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers. The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA). As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found. It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel. We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work. Graz / Austria, May, 1973 in Computers & Automation 21(6B), 30 Aug 1972 view details 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 FacilitiesOne 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 FacilitiesThere 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 ConstructsIt 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 FacilitiesA 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 SoftwareAny 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 Historically SKETCHPAD (Sutherland) was the first widely recognized general purpose graphics system. The SKETCHPAD system consists of a collection of subroutines called interactively through a menu selection process. The system allows pictures to be constructed hierarchically from other pictures and is noted for its use of a ring data structure to store picture descriptions. Kulsrud, Williams, and Giloi presented models for the definition of a general purpose graphics language, Kulsrud suggested that the first version of the proposed language have written commands and that it later be adjusted to accept input from graphics devices such as light pens and trackballs. The language she described was capable of picture description, manipulation, and analysis. Although it could be used with interactive applications programs, it was not an interactive language. Williams described a language that provided (i) data types with related operations particularly suited to graphical applications, and (2) the ability to add new data types and operations. For example, a "point,' could be a data type, and a specially defined addition operator would operate on that data type. The language was thus highly extensible, but it was not interactive. Giloi proposed a model to be used in constructing either subroutine packages for graphic display applications or graphical extensions to existing languages. In this model, pictures were described as a hierarchy of subpictures and picture primitives. Primitives were defined as anything for which there was a hardware generator in the display processor, placing limits on the device independence of a language developed from his model. An interactive version of the model was developed by extending APL to include graphics capabilities, and a non-interactive version was developed as a FORTRAN subroutine package. The general purpose graphics systems presented in recent years can be classified as (i) subroutine packages for graphics applications, (2) graphics extensions to existing languages, and (3) new languages possessing graphics capabilities. Graphics subroutine packages are most widely distributed particularly by manufacturers of graphics display hardware. Some example packages are GINO-F, GPGS, GRAF, DISSPLA, and EXPLOR. Most packages are limited to the manipulation of picture displays with few programming control or storage capabilities. Where such abilities are available they often serve specialized purposes as in WAVE, a package for waveform analysis. One exception is the VIP system where the user is able to combine the available system function subroutines into special purpose functions which can then be used in the same way that the original system functions were used. Extensions of an existing language such as Euler-G, IMAGE, APLBAGS, APLG, and PENCIL, provide a programmer with graphics capabilities as well as general programming features. Euler-G has excellent data structure definition facilities. IMAGE, an extension of FORTRAN, cannot provide the data structure description capabilities that are available in Euler-G, but it has the advantage of being based on the most widely distributed host language available. APLBAGS, APLG, and PENCIL, an extension of the MULTILANG on-line programming system, are truly conversational languages. GRASP, a PL/I extension, is a compiled language but it allows dynamic interaction. GRASP also allows the definition of models from which complex pictures can be created hierarchically. ESP3, an extension of SNOBOL4, is a non-interactive language from which many of the high-level concepts found in PIGLI are drawn. Language extensions are found mainly in experimental installations. Two complete graphics languages are METAVISU and GLIDE. Both take characteristics from a base language (PL/I and ALGOL, respectively) and add capabilities for defining, displaying, and manipulating pictures. Full languages are less widely distributed than subroutine packages or language extensions. in Proceedings of the 1978 annual conference 1978, Washington, D.C., United States view details |