|
|
|
|
10.2 Encapsulating Explicit Mechanisms in Tacit FormsThe Hermes language has been designed to minimize the amount of programming language doctrine required as explicit knowledge by people writing and reading expressions in the language. This has been accomplished by hiding a number of programming language mechanisms in the syntax options of the Hermes language so they can be used with only a tacit understanding of their functioning. This section illustrates what is meant by this approach. A number of important areas of programming language doctrine that require explicit understanding for the use of languages like Lisp or Pascal are incorporated in the syntax options, evaluation processes, and user interfaces of the Hermes language in ways that can be used without explicit understanding. 1. Abstraction in Hermes takes place by simply giving a name to an expression that has been defined; there is no explicit assignment statement. All expressions in the Hermes language can be named and the names may be used wherever the corresponding expression could be used. 2. Iteration is implicit in Hermes. For instance, in the example of displaying the discussion of an item from the Design Rationale window, all the issue links from the item’s node were followed. Normally, this would be expressed in a traditional programming language as some form of iteration (a for-loop or a recursion). However, in the Hermes language it is not expressed at all, but merely assumed in the declaration calling for a list of the issues. 3. Typing of expressions is enforced by restrictions on the allowable syntax options, without the user needing to be aware of this. 4. Recursion is an important technique for navigating successive links in hypermedia networks using the Hermes language, but users need not be aware of it or worry about halting conditions. 5. Variable binding occurs as a natural result of the syntax of expressions, but explicit variables are not used. 6. The syntax allows one to quantify expressions by asking for all items, checking for at least one item, and so on, but the computational implementation of these is hidden from the user. 7. Conditionals can be stated in explicit if / then format or implied through more tacit formats. 1. Abstraction. The importance of abstraction has been emphasized by many leading language designers (e.g., Liskov, et al., 1977; Cardelli & Wegner, 1985; Abelson & Sussman, 1985; Wirth, 1988). From a people-centered perspective, the importance of abstraction in definition of expressions in a programming language is that a complex expression can be hidden under an easy-to-use name that corresponds to terminology in the application domain. That means that the name can be used in a relatively tacit way once it has been defined explicitly. To use an example from Chapter 3, it may be quite difficult to define an operational definition of privacy for lunar habitats. Such a definition must be spelled out in complete and explicit detail (see Section 10.3 below for such a definition) so that the computer system can use it. However, once defined, the definition can be stored under the name privacy. From then on, designers using the system can make use of the term privacy without being concerned about all the computational details. In fact, the term may have been defined as part of the system’s knowledge seed by the software developers or by some intermediate knowledge engineer, so that the lunar habitat designers never need to be concerned with (or develop the skills to understand) the technical details of implementation. This is a case in which the analysis of interpretation provides a new argument about the role of abstraction, an old technique. Based on this argument, Hermes in fact places considerable emphasis on this form of abstraction in the design of the Hermes language, allowing every object stored in the computer memory—including all defined expressions and sub-expressions in the language—to be referred to by user-defined names. The use of abstraction in Hermes supports extensibility of the language. Not only can link Types and node Kinds be user-defined (as they already were in Phidias), but so can the language’s namable terminology elements: Count, Quantifier, and Measure. For instance, a new Count term, several, could be defined as: more than 2 and less than 7. By naming the expression “several,” a user can then make use of this term without worrying about its precise definition. Of course, if another user interprets the term several differently, the definition can always be explored and modified through the interface to the language. Similarly, Measure terms can be added to the language, like “set off from”: central distance is less than 24 inches and closest distance is more than 4 inches In Section 9.1’s scenario in which the notion of privacy is made operational, the scale of privacy values from 1 to 9 was abstracted by the definition of the following Number terms: very public: 1 quite public: 2 public: 3 somewhat public: 4 neutral: 5 somewhat private: 6 private: 7 quite private: 8 very private: 9 These definitions allow designers to think in tacit problem domain terms rather than in the explicit quantitative terms required by the computer. The abstractions are constructed tacitly by simply supplying a name when an expression is defined; there are no explicit assignment statements in the language. 2. Iteration. Much traditional programming language doctrine has to do with iteration: for loops versus while control statements, recursive list processing, sequential comparisons, etc. In Hermes, there are no explicit control structures for iteration. Yet, iterating through lists (e.g., all the nodes of such and such a description, or all the links of a certain Type from a node) is ubiquitous in its central task of navigating through hypermedia. In the Hermes language, the various iterative tasks of the design environment and of its hypermedia substrate are encapsulated in primitive syntax options. A Simple DataList can be defined by a NodeKind or LanguageType; these options iterate through the database index to retrieve all nodes of the specified category. A Simple Association can be defined by a Link Type; this option iterates through all the links of the specified Type from a given starting node. The option, all associations, iterates through all of a node’s out-going links; inverse Association iterates in-coming links; parts iterates content links. Each of these options returns the list of all nodes at the other end of these links. The options are implemented with iteration control structures, but the user need not be aware of this. Simple Filters also iterate through lists of nodes. They test each node successively to see whether it meets some condition. The nodes that meet the condition are returned. For instance, the expression, arguments of answers of the bunk locations issue that are of kind pro-argument, will be evaluated by iterating through all the nodes at the ends of the specified argument links and testing which of them are of node Kind pro-argument. Several of the Number options are also implicitly iterative, returning a count of elements in a list, a minimum, maximum, total, or product of the values. One Number option even iterates through all combinations of two or three graphical objects to return a list of the distances between them. To test for an acceptable work triangle in a kitchen, a designer can simply take the minimum value of this list of distances, without needing to worry about the details of iterating through all the combinatorial possibilities if there are multiple stoves, sinks, or refrigerators in the kitchen. 3. Typing. The constrained syntax of the Hermes language provides an implicit typing system. Like the strong typing system of languages like Pascal, it avoids syntactic combinations that would be meaningless or cause conflicts. However, it is enforced “behind the scenes” so users do not have to be aware of it as a typing system. Types are not declared explicitly by the user. The Simple syntax options are categorized in the syntax classes discussed in the previous section, such as DataList, Filter, and Association. These 25 classes are the types of the Hermes language. A typical Computed syntax option combines terms from several of these classes. For instance, one Computed DataList option is: DataList Combination DataList. This joins any two expressions of type DataList with any expression of type Combination, like and or or. Notice that each of the computed syntax options listed in Appendix C refers to one or more syntax classes (or types). Legal combinations of these types are defined by the options of the syntax. This is a convention of the language; it would be possible to define combinations of individual options or to distinguish between categories of options like Simple and Computed—but that would be a different language. For instance, example a-2 in Table 10-3 allows a DataList to be defined as a Filter applied to a DataList. This means that any expression of type Filter can be applied to any expression of type DataList and the result will be a legal expression of type DataList. The DataList used as a component in this definition may itself be a Computed DataList composed of several components. By applying these rules repeatedly, one can build up well-defined expressions of arbitrary nested complexity. The set of defined legal options has been carefully designed to permit the construction of a broad range of expressions to meet the needs of people using a hypermedia-based design environment. While generality of expression has been a priority, an attempt has also been made to exclude combinations that would lead to problems for the users. Another constraint has been to keep the sheer number of options as small as possible. Of the 110 options defined, only a small number will be used most of the time; many are for advanced techniques primarily necessary for internal use building interface functionality or for complex graphical computations. 4. Recursion. Recursion was already available in the Phidias query language. A simple example is the definition of issue trees as: issues with their issue trees. Here, the definition recursively incorporates its own name. This is useful for navigating hypermedia networks to arbitrary depth. The evaluation proceeds from a node across all its issue links to new nodes, across their issue links, etc. The recursion terminates at nodes that have no issue links. This graceful termination condition is built into the implementation of the Simple Association option, Link Type. Therefore, users of the language do not need to be concerned about explicitly stating a halting condition for the recursion, a step that frequently causes bugs for novice programmers. The implementation supports what a naive user would tacitly expect, or at least what one would come to expect after having been exposed to some sample recursive definitions in the language. 5. Variables. The Hermes language experiments with how far a programming language can go without the use of explicit variables. Variables are perhaps the first serious barrier that most programming poses for people who are not mathematically inclined or experienced. Lack of explicit variables differentiates the Hermes language clearly from procedural languages (that use variables for iteration counters, subroutine parameters, array indices, etc.), functional languages (that use variables for lambda parameters), and logic languages (that use variables for quantification). Hermes makes use of operator application, applying successive operations directly to the results of previous operations without need for abstract variables to relate the operations to the operands. This works smoothly in simple cases and supports tacit expectations. When expressions are nested several levels deep, the relations of what operations are to be applied to which operands can become confusing. (Several examples of this are given in Section 10.3 and in Appendix B, in which moderately complex applications in the Hermes language are discussed.) For these cases, three special “deictic variables” have been defined. These are not abstract variables, but terms that perform much the same concrete role as deictic pronouns in natural languages. The deictic variables of Hermes are the following Simple DataList options: that (last subject), this (expression), and those items. They are used within an expression to refer to a node or list of nodes that has been previously computed. They disambiguate the application of Predicates and allow intermediate results of computations to be displayed or reused without recomputing them. Examples of the use of the it and them deictic variables will be seen in the analysis of the privacy critics in the following section. The this (expression) variable can be useful in defining recursive terms; issue trees can be defined as: issues with their this (expression), where this (expression) refers to the term issue trees that is itself being defined. It should be noted that the lack of variables is a trade-off in the design of the Hermes language. It is intended to reduce the cognitive overhead of the use of explicit variables. However, it probably introduces the most severe restriction in the expressibility of the language for relatively complex computations, making critics like the privacy gradient critique in Section 10.3 and the advice critic in the academic advising application in Appendix B difficult to construct and comprehend. However, the language is not meant primarily to be used for building computationally complex systems, but rather for supporting the incessant reuse and modification of relatively simple definitions of terms needed for displaying, analyzing, and critiquing hypermedia representations of designs. 6. Quantification. The Hermes Quantifier type is provided to support quantification. As just discussed, it does not use the explicit bound variables of predicate calculus or Prolog. Three examples show how it is used:
As should be clear from these expressions, the computation of a quantity like all is carried out internally by the implementation of this syntax option and need not be an explicit concern of the user. 7. Conditionals. Conditionals are important in a design environment. They are, for instance, used for critic rules, conditional links, and conditional nodes. In addition to the standard syntax form for conditionals, if Boolean then DataList1, else DataList2, Hermes offers the following form: either DataList1 or DataList2. The second format is more supportive of a tacit approach. Its evaluation first computes DataList1. If it returns something, that is returned as the result of the whole conditional expression; if it returns no nodes, then DataList2 is computed and its results are returned for the conditional. For instance, if one wants to list the answers to an issue if there are any and give a warning message otherwise, one can define the following conditional expression: either answers of my issue or “There are no answers to my issue.” The implementation of this option takes care of the checking of whether there are any results of the first part and deciding whether or not to compute and return the results of the second part.
Go to top of this page Return to Gerry Stahl's Home Page Send email to Gerry.Stahl@drexel.edu This page last modified on January 05, 2004 |
