GLIDE(ID:4141/gli001)

• Country: us
  • languages for us
  • us/1977
• Began: 1977
  • Languages for 1977
  • 1970s languages
  • Fourth generation
  • High Cold War

Eastman, C.; and Henrion, M.; "GLIDE - A Language for Design Information Systems" view details Extract: Introduction
Introduction

A primary means for evolving more powerful computer software is through the embedding of higher level features into problem-oriented languages. To late, CAD (computer-aided design) systems have had to begin development from FORTRAN, PL/1 or language of similar level. Yet there are needs common to many CAD applications which could be provided in the language or system foundation from which they are developed. GLIDE (Graphical Language for Interactive DEsign) is an attempt to organize the commonly -needed database, features and operations for the design of physical systems into a high level computing environment. By "physical system" we mean artifacts such as buildings, ships and machines, that are made up of a 3-dimensional components and in which spatial arrangement is an important concern. GLIDE is intended to provide an efficient computer representation for physical systems in sufficient detail for their design and construction.

The provision of a complete and coherent computer-based model of 3-dimensional objects and their spatial arrangement offers many advantages over conventional specifications and drawings. Given a complete 3-dimensional spatial representation of the artifact being designed, the designer is guaranteed that all 2-dimensional projections generated from it will be consistent. Shape information, normally represented in drawings, can be integrated with functional and performance information so that application programs can access and manipulate both kinds, without the manual translation now required for drawings. These application programs can check data consistency, evaluate the design's structural, thermal or other properties, estimate cost, or add conventional details. Others can generate displays, construction drawings and numerical control tapes from the stored shape information, which will have guaranteed correspondence with the design. Many such programs already exist and more can be imagined for specific applications in different fields of design.

One can distinguish three levels of representation for 3-dimensional elements:

1 An IMAGE that contains sufficient information for generation of graphics, possibly including hidden line or surface elimination. This usually consists of an unstructured set of planar or curved faces.

2 A SHAPE model represents elements as solid bodies, usually polyhedral. It is spatially complete, meaning that it has a closed, volume-containing surface which contains sufficient information to determine whether any point is inside or outside. For the shape sculpting operations of union, intersection and difference on spatial domains, such a representation is essential [3].

3 An OBJECT model extends this shape model to include functional information, such as material, weight, rigidity etc. Thus shape may be only one attribute among many others which describe the object.

There now exist a wide range of computer languages for 2-D graphics applications, implemented as subroutine packages, or as extended or entirely new languages. While many of these can and have been extended to deal with 3-D IMAGES, only recently has there been work in developing general Shape models [1,17].

Most systems capable of full Shape modeling are controlled by a non-extendable interactive command language [2,3,81. A few are imbedded in general procedural languages, both interpretive and compiled [4,10,11]. Several of these can store command strings on disk and in this way represent large physical system projects that can be repeatedly accessed and modified over a period of time. A few store information on disk in a run-time format, allowing interactive manipulation of large amounts of data [8,16] Several large CAD systems also support object models with comprehensive non-spatial attributes, but whose shape models do not extend to general polyhedra [5,12,20].

In GLIDE, we have attempted to combine the most desirable mix of these features that would be useful as a high level environment for physical systems CAD. The authors are members of a team at Carnegie-Mellon University that earlier implemented a prototype interactive design database called BDS (Building Description System) [8]. GLIDE incorporates many, of the principles developed in BDS, including the compact representation of a large number of complete shape models, the shape -manipulating operations of union, intersection and difference, and several methods for the user definition of shapes. It embodies those facilities in a general high-level language and extends them with additional constructs for making functionally complete object descriptions and for relating objects to each other.

GLIDE is intended to combine the advantages of an interpreted command language for interactive design with those of a procedural programming language. It does not provide highly specialized programs for particular applications, but rather is a general language, with object modeling capabilities in a database environment that incorporates disk management facilities and specialized accessing schemes. It is intended to form a convenient basis for constructing a new generation of more powerful CAD applications. In this paper, we outline the conceptual approach taken in the design of GLIDE. We shall focus of the features which we consider to be of particular importance in the design of design information systems.

The complete specification of GLIDE is available in [6]. It has been implemented on a PDP-10, under the TOPS-10 operating system, using the Bliss implementation language. Implementation is also planned for a PDP-11/34, under the UNIX operating system. Versions are anticipated for both storage tube and refresh display graphics.
Extract: Basic Features
Basic Features:

GLIDE incorporates the basic features of a general purpose Algol-like language. These are fairly conventional and so we will not describe them in detail. They include the following: the simple data types of INTEGER, REAL, BOOLEAN and TEXT (i.e. character string); variables of these types must be declared before use and may be scalar or vectors; the standard arithmetic, comparative and logical operators; the single-value assignment operator; control structures including, the IF THEN e ELSE e. and FOR and WHILE loops; a hierarchical structure of blocks delimited by BEGIN and END, with dynamic declaration of local variables, and user-definable procedures. Flow of control can  also be changed by the escape statements: LEAVE. EXIT and RETURN, for escaping from a BEGIN...END block, the body of a loop, and of a procedure, respectively.

The language is "expression-oriented" that is, every statement returns a value and can be used as part of a higher level expression. The value of an assignment is the value assigned.

The value of an IF statement or block is that part of the last statement executed. Procedures may act as functions and return a value when cal led. The escape statements return the value of the expression following it to the construct from which they escape, eg. the value RETURNed by a procedure. Wherever a statement is treated as an expression, its type must match that expected by the context.

As a database definition language GLIDE calso contains the means for creating record types for defining objects, their shapes and their relationships. The general record type for defining a class of objects is a FORM, whose instances are COPIES. There are also two special record types for defining shapes: TOPO for defining surface topologies, and POLY for defining polyhedral shapes. A SET consists of a collection of Copies or other Sets. Copies and Sets can be treated as equivalent in many contexts and the union of their types is an ITEM. These record types will be described in more detail. Extract: Forms and Copies
Forms and Copies:
FORMS are user-defined complex datatypes somewhat analogous to the Record of PL/1 and Pascal. Struct of Algol-68, or Record class or the Relation of database definition languages. In design databases it is usual to encounter families of objects that have many but not all properties in common. Examples might be a class of doors in a building which have similar shape but different locations, finishes and handles; or a class of container vessels in a chemical process plant. In this situation it is convenient to define a FORM not only as a "schema" which defines the ATTRIBUTES of a class of objects, but also as a "prototype" which contains the initial default values for objects derived from it. For this reason the instances or occurrences of a Form are known as its COPIES. To define a COPY it is only necessary to specify its Form and those Attribute values which differ from it. This allows more concise entry of data and is also used in the current implementation for achieving compact storage of data. The advantages of this organization will become especially apparent when we consider the spatial Attributes for shape and location.

The functional properties of importance in different areas of design vary greatly. User defined Attributes are provided for representing these properties of an object. Attributes may be of any simple type, including vectors of fixed size, or any record type (actually references to records). Since the same Attribute name, eg. COLOR or MATERIAL, may be relevant to many different Forms, they are declared global rather than local to a particular Form definition. Attribute declarations are introduced by the keyword ATTRIB:


A Form definition consists of a block containing Attribute initializations and possibly other statements enclosed between BFORM and EFORM. (These block delimiters are intended to aid type checking, but for conciseness can be replaced by "(" and "I", as can the delimiters for all the other record definition blocks to be described.)

Copies are identified by subscripts appended to their Form. (The Form in its role as "prototype" may also be treated as the zeroth Copy.) In the Copy definition the subscript may be specified or defaulted, as the integer after the previous highest. The Copy definition block delimiters are "{" and "}".

Form identifiers and Copies are bound permanently to their definition and cannot be reassigned. The bind operation is denoted by =, as distinct from the assignment operator "-". However, the individual Attribute values can be modified and a Form or a Copy can be dynamically expanded by the addition of new Attributes. Note that changing a Form Attribute will affect all Copies with the default value; but new individual values may be assigned to an Attribute of a Copy that was originally defaulted. These changes are achieved in a modification block, attached to the object name with a ":":

This dynamic extension of record formats is not allowed in most languages and it adds some complexities to implementation. However we feel it to be important in a database system oriented to interactive design, where simple structures may be created initially which are later refined and elaborated in ways that could not have been anticipated at the start of the process. It also allows set membership information to be added to objects incrementally without any prior restriction on the range of Sets. Attributes needed for a particular kind of analysis may also be appended to objects whenever the need is identified.

Outside a definition or modification block an Attribute value can be accessed by the syntax:
OF
Since the names of Forms and hence of Copies are permanently, bound it is frequently desirable to use a variable. to refer to such objects. These may be declared to be of type ITEM. An Item can be either a Form, a Copy or a Set of Items. An Item variable may be assigned and reassigned by the "<-" operator.

      in Computer Graphics Volume 11, Number 2, July, 1977 Proceedings of SIGGRAPH '77 view details