WARNING: This text has been OCRd from the original paper and so will
contain many typographical errors. It should be useful for
searching, however. [Ash, August 2002].
DEFINITIVE NOTATIONS FOR INTERACTION
Meurig Beynon
University of Warwick, Coventry CV4 7AL, England
Abstract.
This paper explores some methodological and pragmatic aspects of the design of the human-computer interface. In particular, it argues that many interactive dialogues can be formulated conveniently and clearly using notations based upon sequences of definitions ("definitive notations"). Such a notation is an implicit ingredient in the "spread-sheet" packages which have recently become so popular in business applications. To apply similar principles to more complex tasks, such as CAD applications, requires abstraction and generalisation, and poses challenging technical problems.
The three sections of the paper respectively consider: background and motivation, elementary definitive notations (illustrated by an unconventional desk calculator), and complex definitive notations (with particular reference to the design of ARCA, a definitive notation for the interactive description and manipulation of combinatorial diagrams).
Introduction.
The purpose of this paper is to investigate a generic class of programming notations for conducting dialogues. Use of the term "programming notation" rather than "programming language" - as advocated by Dijkstra ([4] p.8) - is more than usually appropriate here, since the applications contemplated are special purpose rather than general purpose. Indeed, the dialogues under consideration are of a relatively simple kind, typically resembling the use of a spread-sheet or some generalisation thereof. Because dialogues in these notations consist of sequences of definitions, the term "definitive notation" is adopted; a pun for which "functional language" is perhaps a good precedent - if indeed definitive notations are as definitive as functional languages are functional. Since a description of the concept of "a definitive notation" is beyond the scope of this brief introduction, the reader may find it helpful to refer to §2 below for details~ at this point.
The paper is in three sections. §1 is concerned with background and motivation, and considers in particular how both procedural and declarative elements are useful in formalisms for dialogue. In §2, the concept of an elementary definitive notation is introduced and illustrated by a simple but unconventional desk calculator based on principles abstracted from spreadsheets. §3 examines the problems encountered in developing generahsed definitive notations suitable for more ambitious applications, and is illustrated with reference to ARCA, a definitive notation for the interactive description and manipulation of combinatorial diagrams.
i--
Background and motivation.
Definitive notations are conceived as a suitable medium for dialogues over some limited universe of discourse. Such a dialogue can be viewed as a sequence of human-computer / computer-human transactions which (it may be reasonably assumed) have common points of reference. In the context of this paper, the term "interaction" is used in its narrow sense to mean "a dialogue in which many transactions occur". In view of the variety of connotations which "interaction" has acquired in computing, some clarification may be helpful. Firstly, the nature of the physical interface (e.g. graphical or textual) is not considered here. Secondly, it is important to recognise that interaction often plays a more incidental role than it might superficially appear. For instance, in solving a problem, interaction may merely entail editing a computer program which is then used directly to determine the required solution. In such a case, the dialogue itself is quite unrelated to the problem to be solved.
Typical pertinent examples of interaction are activities (such as the maintenance of a personal file system, the use of a relational data-base, or the use of a spreadsheet) which are primarily concerned with describing and manipulating a conceptual model with the aid of a computer, rather than the solution of a specific problem. As far as "problem solving" is concerned, the emphasis is on problems in which human experimentation and possibly aesthetic judgement play a part in the solution.
As a motivating example, consider the interaction involved in maintaining a personal system of computer files. The most rudimentary file system provides only a varmbte for each file (viz. a filename) and at any time simply stores the va/ue of each variable (viz. the contents of the appropriate file). In practice, the user has a conceptual model of her file system far richer than the mere set of "variable values" stored by the computer. For example, certain families of files relate to particular subjects, and within such families there are functional relationships between files, such as
"S is the source of the object file 0".
Problems of interaction typically arise when a user resumes a dialogue about her file system after a lapse of time. Though file/subject association can be assisted by filenarne mnemonics on the part of the user, or the existence of directories in the file system, the identification of functional relationships often remains difficult.
The example illustrates difficulties which are common to many dialogues. When a suspended dialogue is resumed, it is desirable that - as far a possible -the conceptual model which the user requires can be readily reconstructed. Taking the above example as a paradigm, it will be assumed that the user's conceptual model can be represented by a set of variables together with
(a) a set of current values
and (b) a set of functional relationships between variables.
It will be convenient to refer to (a) as the set of tr-n.s/ew2 values, and (b) as the set of pets/stew2 relalisn~. This terminology reflects the fact that, in the
context of a particular dialogue, relationships between variables tend to be stable, whilst values are generally subject to change. Thus (in the above example) the contents of the source file S may be revised many times, but the relationship between O and S will be maintained through re-compilation. As explained below, it is significant that neither "transience" nor "persistence" is interpreted too literally. In practical terms, fixing the value of a variable can be viewed as "defining a functional relationship", whilst it is sometimes appropriate to modify an existing functional relationship in the course of a dialogue e.g. 0 rmght be defined by compiling S with different options at different stages of program development. More generally, a mode of dialogue which does not permit convenient modification of both values and relations is too inflexible.
The manipulation of "transient values" and the specification of "persistent relations" are the respective characteristics of the procedzLza/ and decl-.rat~ve approaches to programming. Strictly speaking, the term "declarative" is legitimate only where "referential transparency" pertains, which in this context would preclud~ re-definition of variables once defined. It is nevertheless useful to think in terms of these classifications, using "declarative" in a relative sense to describe definitions which apply throughout a series of transactions, but are not necessarily eternally valid.
Subject to this qualification, the above discussion suggests that a good formalism for a dialogue requires both proce~r~ elements (viz. re-assignment of transient values) and daclarat~ve elements (viz. functional definition of persistent relationships). In particular, a purely procedural formalism is not well-adapted for dealing with persistent relationships. For instance, the traditional procedural emphasis of most operating systems means that the user must update the object file O explicitly whenever the source file S is modified. In effect, monitoring persistent relations is the responsibility of the user. Even where some provision is made for relationships between files to be recorded (as in the "make" utility in UNIX), the updating procedure still has to be invoked explicitly.
As for purely declarative formalisms for dialogue, referential transparency is a strong restrictiorL A paradigm for a declarative program is "specifying a system of equations to be solved by the computer": a single transaction which -if dialogue is to be meanJngful - may either be seen as defining a function (as in "programming with equations" [5]) or as defining a functional relationship between variables (as in "programming with constraints" [3]). In the former case, such a function might correspond to the aggregate of (strictly) persistent relations, and its parameters to the (implicit) variables to which transient values can be assigned, but not in general in such a way as to make the updating required for dialogue convenient. ]n the latter case, the cumulative adjunction of equational constraints, whilst appropriate when iterating towards the solution of a specific problem, inhibits dialogue unless some provision is made for modifying or forgetting constraints. Despite these difficulties, the use of declarative principles has a distinguished pedigree in such remarkable "object-oriented language" systems as APT (Douglas Ross [8]), SKETCHPAD (I.Sutherland
4
[i0]) and ThingLab (Alan Borning [8]). The objectives of ThingLab in particular are topical in this context, and it would be interesting to understand how the use of definitive notations is related to the constraint-oriented approach taken in [8].
The formalism for interaction proposed in this paper reflects the ideas above. It will be assumed that the user's conceptual model is defined with reference to an underlying algebra appropriate for the universe of discourse. This algebra might be "integers with arithmetic operators" (using a spreadsheet), "relational algebra" (using a relational data-base) or "files with file operations such as concatenation, compilation, compaction etc." (maintaining a file system). The dialogue between user and computer is then expressed in terms of variables which may if defined have associated values in the underlying algebra. The values of these variables play the role of the "transient values", and the persistent relations are formulae which define the value of a variable in terms of the values of other variables and constant values using the operators of the underlying" algebra. In the context of the illustrative example above: the file variables S and O respectively denote source and object files, the values of the variables S and O are their respective contents, and "O=compile(S)" is a persistent relation defining the contents of the corresponding object file.
Use of a spread-sheet is a simple example of interaction along these lines. In a spread-sheet system, in its simplest form, scalar variables can be prescribed to correspond with entries in a displayed table. Each variable can then be given an explicit scalar value, or assigned a arithmetic formula specifying how its value is to be computed from the values of other variables. Spread-sheets have proved to be a very popular and effective medium for numerical calculations in which experin~ents with parameters play a part. Perhaps the most attractive feature of this approach is that both persistent relations and transient values are stored by the computer, and the effect of changing the value of a particular variable can be automatically computed and displayed.
The same pattern of interaction is used in the relational algebra query language ISBL ([ii] p.177-181). In this context, the relationship between the "intension" of a data-base relation (or equivalently, a v/e%u) and its extension at a particular time corresponds precisely to the relationship between a defining formula and its current value. The definition of views by "delayed evaluation" is then semantically equivalent to formula definition in a definitive notation based upon relational algebra. Indeed, the distinction between ISBL and a definitive notation is purely syntactic - the syntax in ISq3L being biased towards value assignment rather than formula assignment.
Elementary definitive notaUons.
In this section, the basic concept of a "definitive notation" is described and illustrated with reference to a simple but unconventional desk-calculator (udc) based upon principles abstracted from spread-sheets. ]n the interest of brevity and readability, formal details are omitted, but the reader should require little
imagination to supply these.
Informally, a definitive notation is associated with an "underlying algebra"
which is chosen to reflect the universe of discourse. Variables in the definitive
notation are used to denote elements of the underlying algebra, and a typical
program consists of a sequence of statements, each of which defines a variable
or interrogates a variable. Definitions in such a notation can be conceptually
regarded as being of two types: fsrna~/a assignment such as
a = f(b,c z)
(semantically: unless and until a is re-defined, its value is determined as
required by evaluating the formula f(b,c z) over the underlying algebra), and
value assignment
a=C
(semantically: unless and until a is re-defined, it has the explicit value C). In this context, formulae are defined in terms of the operators of the underlying algebra, and the expression Igl can be used to denote "the value of the formula g" as required..After a sequence of definitions, the value of a particular variable - which may be undefined - will in general depend upon the definitions of a set of variables in a non-recursive manner. Interrogation of a variable or formula can then be used to determine the family of definitions upon which its value notionally depends, and to determine its value if it exists.
In the simple case of the udc, the underlying algebra is the set of integers together with an appropriate set of operators, which is here assumed to contain standard arithmetic and relational operators, and an arithmetic "if --" then--- else". ]t should be clear that the udc is essentially a primitive spread sheet from which the tabular interface has been removed. It may also be observed that in any udc dialogue, the current values of variables and a~gebraic relationships between variables are easily determined at any stage. The essential characteristics of udc dialogue are illustrated below; the formal specification of the udc is left as an exercise to the imaginative reader.
In the udc, the assignment "a = b+c*4" associates the forr~la "b+c*4" with the identifier a, specifying that (until a is re-defined) the value of a is to be determined, as and when required, by evaluating the formula "b+c*4". Thus the value of a is implicitly rather than explicitly defined, and the values of b and c at the point of definition are irrelevant, and need not be defined. There is then a distinction between "a is undefined" (ie. there is no formula currently associated with a), and "the value of a is undefined" (ie. either a is undefllned, or the value of a is defined by a formula which currently has no evaluation).
As a simple example of a udc dialogue, consider the following sequence of
definitions:
i. e=if b