Copyright 1997 IEEE. Published in the Proceedings of VL’96, September 6–9, 1996 in Boulder, Colorado, USA. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works, must be obtained from the IEEE. Contact: Manager, Copyrights and Permissions / IEEE Service Center / 445 Hoes Lane / P.O. Box 1331 / Piscataway, NJ 08855-1331, USA. Telephone: + Intl. 908-562-3966.
A Visual Logic Programming Language Jordi PUIGSEGUR 1 , Jaume AGUST´I 1 , Dave ROBERTSON 2 1
Institut d’Investigaci´o en Intellig`encia Artificial (CSIC) Campus UAB, 08193 Bellaterra, CATALONIA (Spain) 2 Department of Artificial Intelligence, University of Edinburgh 80 South Bridge, Edinburgh, SCOTLAND (UK) e-mail: fjpf,
[email protected],
[email protected]
Abstract It is commonly accepted that non-logicians have difficulty in expressing themselves in first order logic. Part of the visual language community is concerned with providing visual notations (“declarative diagrams”) which use visual cues to make the structuring of logical expressions more intuitive. One of the more successful metaphors used in such languages is that of set inclusion, making use of the graphical intuitions which most of us are taught at school. Existing declarative diagramming languages do not make full use of such set-based intuitions. We present a more uniform use of sets in this form of description, which allows simple, but highly expressive diagrams to be constructed from a small number of primitive components. These diagrams —we claim— provide a good alternative notation for a limited, but useful, subset of FOL and, as we show in this paper, are the basis of a visual logic programming language.
gramming languages (VPL). From VPL we borrow the experience in designing programming languages using visual syntax. Subjects like the interactive behaviour of a visual language, the problems that arise in large programs and applications (see [6]) or even the cognitive aspects derived from the use of visual representations —which have been long studied in the VPL comunity— provide a context for our work. However, its concrete starting point was diagrammatic reasoning as presented by Eric Hammer in [10]. This presents a visual language for which there is a close correspondence to FOL. The main goal of [10] and also that of [4, 3] is to reason with diagrammatic representations because they correspond more closely to our physical intuitions than the usual mathematical notation. visual logic programming logic
visual languages expertise
diagrammatic reasoning
1. Introduction
logic programming
We are interested in “intuitive” forms of problem description within a complete formal language. To be widely used, formal languages should not present undue difficulties of use and interpretation to the persons who create and read the specifications, usually experts on the application domain and not programmers (see [15]). Visual languages are appealing candidates for performing this task, helping to bridge the gap between the informal description of a problem and its first formal description. The visualization ideas behind this work come mainly from two areas: diagrammatic reasoning and visual pro This work was supported by the project DISCOR (TIC 94-0847-C0201) funded by the CICYT
We want to have an expressive representation of FOL which makes as much use as possible of simple visual cues in its description. For this purpose the higraph notation of [10] provides too much detail and is therefore difficult to use. To be able to use this notation properly, a user must know about predicates and arguments, variable matching, simple lambda expressions and implicit implication. We consider this to be too much of an overhead for initial formal specifications. In the next section we describe an alternative notation which does not require users to deal with some of these concepts directly. The resulting visual language is radically different from that of [10], but —we
claim— it provides a much “softer” route into FOL specification. In particular, in Section 3 we show how it can be used as a visual syntax for pure Prolog.
2. A Visual Logic A keypoint in the definition of a visual logic is to choose the right visual syntax. Our choice has been a customisation of higraphs, a topological formalism developped by David Harel (see [11]) that combines VENN diagrams together with graphs. Higraphs actually are graphs where some nodes are related by a partial order relation (graphical inclusion) or from the other point of view, Venn diagrams where the sets are related by a binary relation, graphically shown by means of arrows. The higraph approach to declarative diagramming is closely related to our approach. In fact, the core ideas of our work are to represent graphically logical predicates via the set of elements that satisfy them, and to represent the terms as graphs. Thus logical terms are represented as graphs and instead of logical predicates we specify sets by means of inclusion relations between them. To further exploit the properties of this diagrammatic formalism, we use a syntax where the composition of relations can be expressed in the same way as function composition. A similar syntax, called taxonomic syntax, was designed by McAllester in [12, 13]. In this type of syntax we have class terms (also set terms), referring to the fact that these terms constructed from predicates represent sets of elements. Actually, they can be seen as logical constrains over elements that implicitly determine a set.
prefixed by an asterisk, ‘t’. - Given two set terms t1 and t2 , t1 \ t2 and t1 [ t2 are also set terms. - Nothing else is a set term. Notice that in the construction of set terms as predicate applications there is always one argument less than the arity of the predicate. The reason is that one of the arguments — by convention the last one— is always left free, so that the set term defines the logical constraint over that argument. In the following examples we can see how some set terms are constructed and their interpretation: Predicate Symbol
man (arity 1) likes (arity 2)
In our visual logic we have two different types of terms: FOL terms that represent elements, and this new type of terms called set terms that represent sets of elements that satisfy a given predicate. Let us see first the textual definition of these two types of terms: Definition 1 (FOL Terms) - A variable (x; y; z; :::) is a FOL term. - A constant (a; b; c; :::) is a FOL term. - A functional application f (t1 ; :::tn ) is a FOL term, where f is an n-ary function symbol (f; g; h; ::: of arity n 1) and t1 ; :::; tn are FOL terms. - Nothing else is a FOL term. Definition 2 (Set Terms) - A unary predicate p is a set term. - A predicate application p(s1 ; :::; sn?1 ) is a set term, where p is an n-ary predicate symbol (p; q; r; ::: of arity n 2) and s1 ; ::; sn?1 are either FOL terms, set terms or set terms
Interpretation
man fx j man(x)g likes(x) fy j likes(x; y)g
The other way to construct set terms is as unions or intersections of other set terms. These two constructs are equivalent to the disjunction and the conjuction connectives in standard FOL, and their interpretation is the union and intersection of the sets associated to the set terms. Now let us study how the composition of predicates works. As we can see in definition 2, there are two types of predicate composition: q (:::; p(:::); :::) and q(:::; p(:::); :::). The first case indicates that we are interested in the elements that hold the predicate q for some element belonging to the set term p(:::), while in the second case we are interested in the elements that hold the predicate q for all the elements satisfying the set term p(:::). In the following table there are examples of both types of predicate composition. Set Term
2.1. Terms
Set Term
likes(man)
Interpretation Set of things that some man likes.
likes(man)
Set of things that every man likes.
fx j 9y [likes(y; x) ^ man(y)]g
fx j 8y [likes(y; x) ( man(y)]g
Definition 3 (Semantic Interp. of FOL Terms) Let A be a first order model with semantic domain jAj and let : V ! jAj be a mapping from variables to elements. We define the semantic interpretation of a FOL term as the function A : T ! jAj that assigns to each FOL term an element of the semantic domain jAj, defined as it is usual in FOL. Definition 4 (Semantic Interp. of Set Terms) Let A be a first order model with semantic domain jAj, let pA be the interpretation of the predicate p in A, and let : V ! jAj be a mapping from variables to elements. We define the semantic interpretation of a set term as the function 'A : S ! P (jAj) that assigns to each set term a subset of the semantic domain jAj, and is defined in the following way:
p p
q
f
p
q
a ... Variables
Constants
Functions
....
....
Predicates
Union
Intersection
Figure 1. Vocabulary of Graphical Symbols p p
likes
f
likes f
q
man
g r
man tall
likes(man)
(likes every man)
likes(man \ tall) (likes some tall man)
q
a
p(q(a; x); x; f (a; y))
p(r \ q(x); x)
a
f (x; g(x; a); y)
Figure 2. Examples of Terms in Visual Logic - unary predicate: 'A (p) = pA - predicate application of an n-ary predicate p (n 1), where t1 ; :::; tn?1 are FOL terms and s1 ; :::; sn?1 are set terms:
'A (p(t1 ; :::; tn?1 )) = fx j h A (t1 ); :::; A (tn?1 ); xi 2 pA g 'A (p(s1 ; :::; sn?1 )) = fxn j 9x1 ; :::; xn?1 [hx1 ; :::; xn?1 ; xn i 2 pA ^x1 2 'A (s1 ) ^ ::: ^ xn?1 2 'A (sn?1 ) ] g 'A (p(s1 ; :::; sn?1 )) = fxn j 8x1 ; :::; xn?1 [hx1 ; :::; xn?1 ; xn i 2 pA ( (x1 2 'A (s1 ) ^ ::: ^ xn?1 2 'A (sn?1 ) ) ] g
and when different types of arguments are mixed in a predicate application, its interpretation is a combination of the former three cases. For instance:
'A (p(q; r)) = fz j 9y 8x [( p(x; y; z ) ( x 2 'A (q) ) ^ y 2 'A (r)] g
We just have to take care to place the existential quantifiers first, followed by the universal quantifiers. - union and intersection:
'A (s1 [ s2 ) = 'A (s1 ) [ 'A (s2 ) 'A (s1 \ s2 ) = 'A (s1 ) \ 'A (s2 )
In Figure 1 we can see the visual vocabulary, i.e. the graphical symbols that we use as nodes in the higraphs. These diagrammatic elements are boxes, rounded boxes and
circles. Square boxes correspond to set terms while the rest (rounded boxes and circles) correspond to FOL terms. A predicate symbol is represented as a square box with the predicate symbol on a corner, while a function symbol is represented by a rounded box, also with the function symbol on a corner. Circles represent variables. The graphical representation of terms as directed acyclic graphs —both of FOL terms and set terms— is now straightforward. In effect, using the translation from textual symbols to graphical symbols given in Figure 1, we obtain the nodes of the graph. And then we connect those nodes using arrows that point from the subterms to the node that represents the functor of the term (either a predicate symbol or a function symbol). We distinguish the two types of predicate composition by using a double arrow where the textual form uses an asterisk (‘*’). In Figure 2 we give some examples of visual terms, together with their textual form. The representation of all terms using the same formalism, DAGs, is one of the keypoints in our visual language. They allow sharing of common parts of subterms, reducing the quantity of symbols in a term. For example, a variable that appears many times in a textual term, will appear just once in the corresponding visual term.
2.2. Formulas The basic units of our visual language —equivalent to formulas in textual languages— are diagrams. A diagram is
grandparent parent
parent john
ancestor ancestor
mary
peter (a) (a) (b)
ancestor
parent
parent
parent
(b)
john 2 parent(peter) mary 2 parent(peter) parent(parent(x)) grandparent(x)
(c) (c) (d) (e)
(d)
descendant
ancestor
(e)
parent(x) ancestor(x) ancestor(parent(x)) ancestor(x) x 2 descendant(y) ( y 2 ancestor(x)
Figure 3. Examples of Diagrams in Visual Logic the smallest complete unit of description and it is composed of various visual terms related by graphical inclusion. In every diagram there is a goal set term: which is the term that is being defined. To define a set term we indicate which are its elements, giving either the elements explicitly or a subset term. The goal set term is marked by drawing its box using thick lines. The inclusion of a FOL term or a set term in the goal set term is the main inclusion of the diagram, i.e. its conclusion. Optionally the diagram might contain other inclusions that will be conditions. For simplicity of the resulting formulas we only allow the conditions to be inclusions of elements into sets, not sets into sets. Therefore a diagram is equivalent to an inclusional clause1 where the head is the main inclusion and the rest of inclusions in the diagram are the body of the clause. Inclusional clauses are the formulas of our language, and are defined in the following definition: Definition 5 (Formulas) - t 2 p(t1 ; :::; tn ) is a formula, where t; t1 ; :::; tn are FOL terms and p is an n-ary predicate (n 0). - t 2 p(t1 ; :::; tn ) ( t01 2 s1 ^ ::: ^ t0m 2 sm is a formula, where t; t1 ; :::; tn ; t01 ; :::; t0m are FOL terms, s1 ; :::; sm are set terms, m 1 and p is an n-ary predicate (n 0). - s p(t1 ; :::; tn ) is a formula, where s is a set term, t1 ; :::; tn are FOL terms and p is an n-ary predicate (n 0) . - s p(t1 ; :::; tn ) ( t01 2 s1 ^ ::: ^ t0m 2 sm is a formula, where t1 ; :::; tn ; t01 ; :::; t0m are FOL terms, s; s1 ; :::; sm are set terms, m 1 and p is an n-ary predicate (n 0). - Nothing else is a formula. Definition 6 (Semantic Interp. of Formulas) Given an interpretation A we define A j= , where is an 1 Its translation to a FOL formula might not be a Horn clause, due to the use of the universally quantified predicate application.
atomic formula, as:
A j= t 2 s () A (t) 2 'A (s) A j= s1 s2 () 'A (s1 ) 'A (s2 )
The semantic interpretation of non–atomic formulas — where all free variables are considered universally quantified— is defined using the standard interpretation of Boolean connectives in FOL. The logic we have defined is less expressive than FOL. By restricting ourselves to a limited, but useful, subset of full first order logic we are able to avoid some of the notoriously difficult concepts of declarative diagramming, such as explicit variable naming. Figure 3 shows an example of how diagrams are constructed. First, in diagram (a) we give two cases that satisfy the parent relation. In (b) we just state that the parents of the parents of x are the grandparents of x. Next, in diagrams (c) and (d) of the same figure we define the ancestor relation. In the first diagram we state that parents are ancestors and in (d) we formulate the recursive case: the ancestors of the parents of x are also ancestors of x. The last example, diagram(e), defines descendant, the symmetric relation of ancestor, and note that it is a diagram with two inclusions. If we look at the translation to FOL formulas —which is straightforward— of the diagrams in Figure 3:
parent(peter; john) ^ parent(peter; mary) 8x 8x 8x [grandparent(x; z ) ( parent(x; y) ^ parent(y; z )] (c) 8x 8y [ancestor (x; y ) ( parent(x; y )] (d) 8x 8y 8z [ancestor (x; z ) ( parent(x; y) ^ ancestor(y; z )] (e) 8x 8y [descendant(x; y ) ( ancestor (y; x)]
(a)
(b)
we can see some of the advantages of using a visual notation. Whereas in the textual descriptions predicates are
person
son brother
y 2 brother(x) ( x 2 son(z ) ^ y 2 son(z ) ^ z 2 person Figure 4. Brother (1) person
son
brother
person
(a) (a) (b)
son
brother
(b)
son(z ) brother(x) ( x 2 son(z ) ^ z 2 person y 2 brother(x) ( x 2 son(z ) ^ y 2 son(z ) ^ z 2 person Figure 5. Brother (2)
linked —apart from logical connectives— by sharing common variables, in the visual syntax, this links are mainly represented by predicate composition, which is clearly represented in the diagrams. Recursive patterns are also clearly shown in the diagrams but are less evident in the textual FOL descriptions.
2.3. Extended Notation We have presented and formalised a visual logic, based on higraphs and a special syntax allowing predicate composition. So far, what we have defined is enough to be able to produce initial descriptions, but we still have to add some other visual —extra-logic— elements to make it more practical. Let us examine the diagram in Figure 4. It defines the relation brother based on the son relation: it says that the sons of the same person are brothers 2 —beware that in this simple formalisation of brother one is brother of oneself, but we didn’t want to introduce innecessary complexity in this example. This diagram is not as clear as we would like. The partial overlapping of the two sets to allow a common variable slows the comprehension of the diagram. Sometimes it is difficult to organize the boxes and circles in the diagram in a way such that the intended relations are correctly expressed. Furthermore, it is important to have mechanisms that allow us to introduce secondary notation in the diagrams, making it easier to comprehend the ideas behind them. Secondary notation is extra notation that although it does not change the formal meaning, helps the 2 In this example we use the male forms ‘son’ and ‘brother’ but we do not intend to introduce any gender restriction.
user to locate the relevant information in the diagrams (see [14])
We now introduce an element that will improve the language in this direction: the ‘graphical copy’. It is a syntactic facility that allows us to have a copy of a set or an element in any place of the diagram. It consists in an empty box or a circle, joined to the original set or element respectively, by a straight line. In Figure 5 we find two different examples of the use of this facility. Both present a redesign of the brother diagram of Figure 4 and are also logically equivalent. The first of them uses a set copy and the second a variable copy. We claim that they are easier to understand than the first diagram because the relevant information has been highlighted. Although all three diagrams are formally equivalent —they have the same FOL translation— the last two make use of secondary notation to introduce visual cues that allow to say more about what they want to formalize: the brother relation.
The last extra–logical feature we use is arrow–labeling. When the argument ordering of a predicate is relevant, we need to have some mechanism that allows us to distinguish each arrow, linking it to a specific argument position. We do so by labeling the arrows arriving to the box (square or rounded box) with natural numbers that give the position of the argument associated to the arrow. In Figure 6 there is an example of this feature: the functions disj and rule (in diagrams (c),(d) and (e)) have been labeled in order to distinguish the arguments.
solve
solve conj
solve prog_fact
1
solve
solve
solve disj
solve
disj
2
1
solve
1
2
2
solve
rule prog_rule
(a) (a) (b)
(b)
(c)
prog fact solve conj (x; y) 2 solve ( x 2 solve ^ y 2 solve
(d) (c) (d) (e)
(e)
disj (x; y) 2 solve ( x 2 solve disj (x; y) 2 solve ( y 2 solve x 2 solve ( rule(x; y) 2 prog rule ^ y 2 solve
Figure 6. A Prolog Metainterpreter solve(X) :- prog_fact(X). solve(conj(X,Y)) :- solve(X), solve(Y). solve(disj(X,Y)) :- solve(X). solve(disj(X,Y)) :- solve(Y). solve(H) :- prog_rule(rule(H,B)), solve(B). Figure 7. Translation to Textual Prolog of the Metainterpreter described in Figure 6
3. Visual Prolog As a first application of the visual logic presented in the previous section we have designed and implemented a visual alternative syntax for pure Prolog. We have defined our visual logic in such a way that now it is possible to use it as a logic programming language. The formulas that we can obtain are already Horn clauses and therefore any diagram can easily be translated to Prolog. One of the main differences from the visual logic is the change in the treatment of FOL terms constructed by function composition. In a pure logic, a function is evaluated to an element of the domain and its value is used to obtain the truth value of the predicate. Prolog does not have functions but constructors, it permits the construction of complex terms using this constructors. Syntactically, Prolog terms look like any standard FOL term, however they are not treated as function applications and therefore there is no function evaluation. The mechanism that allows the user to work with compound terms is the unification algorithm. Now the FOL terms of our visual logic will be seen as Prolog terms. Other logic programming methodologies that implement equality using narrowing, allow an implementation of terms closer to that of FOL. Now let us see an example of visual programming in Prolog. In Figure 6 we find a visual metainterpreter for Prolog. It is the standard type of “vanilla” metainterpreter, with the
usual cases: (a) the goal is a Prolog fact, (b) it is a conjunction of goals, (c) and (d) a disjunction, or (e) the goal instantiates with the left-hand side of a rule. The translation to Prolog —see Figure 7—, is automatically done by an algorithm that translates our diagrams to Prolog clauses. This algorithm performs a traversal of the higraph constructing at the same time the Prolog clause. We believe that this Visual Prolog syntax will do its best in an heterogeneous environment. In the way it has been designed and implemented, there is a direct translation from diagrams to Prolog Horn Clauses3 . Then it is possible to think of an heterogeneous logic program as a set of Horn Clauses, some of them in textual form while others would be expressed as diagrams. Our intention is to develop an heterogeneous editor that could help and guide the user in the construction of correct diagrams. We are specially interested in editors directed by the syntax and semantics of the diagrams (see [16]) that can help and guide the user in the construction of correct programs. An early version has been implemented —employing a slightly different functionality than the one described in the paper— using LPA MacProlog on Apple Macintosh hardware. Currently, we are implementing the visual language proposed in this section on a Unix platform using 3 The universally quantified arguments are translated into valid Prolog clauses by using negation by failure and assuming the Closed World Assumption.
X-Windows .
4. Other Related Work We already commented in the introduction on the relationship of this work with diagrammatic reasoning work in [10]. Not directly related but in the same spirit is the work in [8] and [5], where a mathematical notation is embedded within a visual representation in order to support its understanding and therefore its use. The work in [8] opens for us a question whether we could combine our visual syntax with VEX in order to visualize higher order logic, i.e. Prolog. As shown in Section 2, the intuitive interpretation of diagrams is based on sets and set inclusion. Set terms and set term inclusions provide an alternative syntax for FOL that is very near to the taxonomic and Montagovian syntax for FOL in [12] and [13] respectively. This non–standard syntax for FOL possesses benefits other than facilitating visualization as shown here. As McAllester claims in [12] and [13] it may make first–order inference more efficient. These three features of our set–based syntax for FOL, first, its efficient inference, second, its intuitive visual presentation and, third, its close relationship with natural language, suggests that it might be a good language for rapid prototyping.
set into a list. We do not mention these extensions here, because of lack of space and also because they are still under development. Our next major step will be the implementation of an heterogeneous Prolog environment, as described in Section 3. The challenge of this work is to achieve a real integration of the visual syntax into textual Prolog. An ideal implementation would rely completely on the visual syntax in all the phases of software development: coding, documentation, debugging, execution, etc. We are specially interested in animation of Prolog execution using our visual Prolog. There have been other attempts to integrate textual and visual languages, like [9], however most of them were not focused on logic programming and therefore did not make full use of the visual benefits of declarative description. We are also interested in exploring other uses of our visual syntax within logic programming. We are currently studying the possibility of solving Prolog queries visually. We also believe that our visual syntax for Prolog could be used in the reverse direction: giving a form of reverse engineering. It could be used as a method to display existing Prolog programs. Finally, the ideas present in this paper could be extended and applied to languages more expressive than Prolog. For instance we have in mind the visualization of LIFE (see [2]).
References 5. Conclusions and Work in Progress Our implementation of the graphical language is still in its early stages and we have performed only limited tests with subjects outside the development group. However, we are encouraged to find that it allows a compact description of some standard problems from the formal specification literature. For instance, in [1] we have graphically specified the example proposed in [17]. We have also observed that description in our system normally follows one of a small number standard pattern of definition —analogous to the standard patterns of formal specification classified by the “techniques editing” section of the logic programming community. This raises our confidence that we can embed the language within a development environment which makes it easy to use by reinforcing these standard forms of expression. There are other extralogical Prolog predicates that would be interesting to have in our diagrams. One obvious extension is the negation by failure predicate: ‘not’. We have studied the possibility of having this predicate in our diagrams, by somehow being able to define a new set term as the complement (by failure) of another set term. A second extension is to include list-set predicates such as ‘member’ or ‘setof’, that in our case would be equivalent to translating an element that is a list into a graphical set or a graphical
[1] Jaume Agust´ı, Dave Robertson, and Jordi Puigsegur. G RA S P: A GRAphical SPecification Language for the Preliminary Specification of Logic Programs. Technical Report IIIA 95/13, Institut d’Investigaci´o en Intellig`encia Artificial, Bellaterra, Catalonia, 1995. [2] Hassan A¨ıt–Kaci and Andreas Podelski. Towards a Meaning of LIFE. Journal of Logic Programming, 16:195–234, 1993. [3] Jon Barwise and John Etchemendy. Hyperprooff. CSLI Publications, Stanford, 1993. [4] Jon Barwise and John Etchemendy. Heterogeneous Logic. In Diagrammatic Logics: Cognitive and Computational Perspectives. AAAI Press and MIT Press, 1995. [5] Alberto Del Bimbo, Luigi Rella, and Enrico Vicario. Visual Specification of Branching Time Temporal Logic. In Proceedings of the 11th IEEE Symposium on Visual Languages, September 1995. [6] Margaret M. Burnett, Marla J. Baker, Carisa Bohus, Paul Carlson, Sherry Yang, and Pieter van Zee. Scaling Up Visual Programming Languages. IEEE Computer, March 1995. [7] Margaret M. Burnett, Adele Goldberg, and Ted G. Lewis, editors. Visual Object-Oriented Programming, Concepts and Environments. Prentice Hall/Manning Publications, Englewood Cliffs, NJ, 1995. [8] Wayne Citrin, Richard Hall, and Benjamin Zorn. Programming with Visual Expressions. In Proceedings of the 11th IEEE Symposium on Visual Languages, September 1995.
[9] Martin Erwig and Bernd Meyer. Heterogeneous Visual Languages –Integrating Visual and Textual Programming–. In Proceedings of the 11th IEEE Symposium on Visual Languages, September 1995. [10] Eric Hammer. Representing Relations Diagrammatically. In Gerard Alwein and Jon Barwise, editors, Working Papers on Diagrams and Logic, Indiana University Logic Group Preprint Series IULG-93-24. Indiana University, 1993. [11] David Harel. On Visual Formalisms. Communications of the ACM, 31(5):514–530, May 1988. [12] David McAllester and Robert Givan. Natural language syntax and first-order inference. Artificial Intelligence, 56:1–20, 1992. [13] David McAllester, Robert Givan, and T. Fatima. Taxonomic Syntax for First Order Inference. Journal of the ACM, 40(2):246–283, 1993. [14] Marian Petre. Why Looking Isn’t Always Seeing: Readership Skills and Graphical Programming. Communications of the ACM, 38(6), June 1995. [15] Dave Robertson, Jaume Agust´ı, Jane Hesketh, and Jordi Levy. Expressing program requirements using refinement lattices. Fundamenta Informaticae, 21:163–182, 1994. [16] J. Artur Serrano. The Use of Semantic Constraints on Diagram Editors. In Proceedings of the 11th IEEE Symposium on Visual Languages, September 1995. [17] Jan Treur and Thomas Wetter, editors. Formal Specification of Complex Reasoning Systems. Ellis Horwood, The Netherlands, 1993. [18] Dejuan Wang. Studies on the Formal Semantics of Pictures. PhD thesis, University of Amsterdam, January 1995.
