DALI(ID:5082/dal001)Graphical display languagefor Display Algorithm Language Interpreter Universal language extension to permit interactive graphic modelling Graphic objects are polled according to set rules by a daemon Related languages
References: Introduction DALI (Display Algorithm Language Interpreter) is a special purpose high level language extension for the creation and control of dynamic pictures, particularly pictures exhibiting complex static and dynamic interactions among their elements. Prior work in this area includes the development of subroutine packages for graphics and languages or language extensions for graphics. Nearly all of these share a common semantic base: they describe pictures as hierarchical data structures capable of representing a small, fixed set of possible relationships between picture elements -- e.g., relative position, relative scale, relative rotation, etc. EULER-G is an exception to this, but it is oriented towards creating static, rather than changing, pictures. DALI differs strongly from such systems in that a DALI picture is not a passive data structure. Instead, a DALI picture is a structure of active elements akin to "processes", containing user-written procedures called daemons which are executed in creating or changing"~ picture. The selection of daemons to run and the choice of their order of execution is defined by a set of scheduling rules, built into the language, which are based on local, low-level functional relationships among daemons, A wide variety of dynamic pictures can be described in DALI, since daemons are arbitrarily user-programmable and can alter both quantitative and oualitative aspects of the picture. E.g., daemons can alter positions, sizes, and orientations of displayed objects; creBte and destroy objects; and alter the functional relationships between objects -- all in response to changes in arbitrarily selectable parameters such as scale, number of objects to be displayed, orientation, etc. A primary advantage to the DALI approach is modularity: each picture element, via its daemons, locally describes its own behavior. In the remainder of this paper, the basic concepts of DALI are presented, followed by some examples; then, certain critical implementation issues are discussed, namely the scheduling rules and DALI's environment structure. Extract: The Base Language The Base Language The language of which DALI is an extension will be referred to as the base language. Essentially any procedural language can be a DALI base language. For example, ALGOL, FORTRAN, PL/I or LISP could be used, albeit with varying degrees of difficulty. PL/I will be used here as a sample base language (LISP has been used elsewhere). We will assume an initial simple extension of PL/I to add the data type POSITION, or POS, defining an (X,Y) position, along with normal vector arithmetic on POSITIONs. Extract: Objects Defined by DALI Objects Defined by DALI As an extension, DALI adds to the base language four primary types of objects: outputs, daemons, picture modules (or just modules structure. Each of these items will now be discussed, and then some examples will be given. Outputs Outputs are locations where data can be stored, and are primarily used for communication. Outputs differ from "normal" storage locations in that a change in value of an output can be detected as an event by one or more active objects (i.e., daemons). Daemons Daemons are parameterless procedures which are executed in response to some event. A particularly important class of events to which daemons can respond is a change in the value of one or more outputs. Since a daemon can alter the value of outputs in response to changes in other outputs, computed changes can be propagated through the entire picture. Picture modules Picture modules are organizational units which contain daemons, outputs, and other picture modules in a hierarchical fashion. The objects contained in a picture module are said to be owned by that module. Picture modules also contara local environment, a mapping from identifiers to values usable only by the daemons owned by the module. Picture functions Picture functions are valued procedures written by the user; they are applied to arguments are return a value. Application of a picture function creates, in lieu of a normal procedural activation, a picture module which remains in existence until explicitly deleted. The created picture module is the value returned by an application of a picture function. A picture function, in addition to being usable in an expression, can be CALLed; in this case, the value returned is ignored. If a picture function is applied by a daemon owned by some picture module, the newly created module is owned by the daemon's owner. This creates a hierarchical structure analogous to the tree of procedure activations which can be created in languages such as CONNIVER and OREGANO. A picture function is defined by the user as follows: name:PICFUN (arguments) options; body of executable code END name; The identifiers appearing as arguments are part of the local environment created when the picture function is invoked. Other identifiers can be included in the local environment by use of various options; this will be illustrated in the examples. The structure created by applying picture functions, creating daemons, etc., is called the picture structure. [...]The data web is a directed graph describing the relationships between daemons and outputs: which daemons can change whicb outputs, and which daemons run when what outputs change value. A daemon which can change a given output's value is said to specify that output; and a daemon which runs when a given output changes value is said to watch that output. The topology of the data web impacts heavily on the scheduling of daemons and will be discussed further later in this paper. in [ACM SIGPPLAN] Proc ACM Symp on Graphic Languages, Apr 1976 view details |