FMUFL: A fuzzy multi-paradigm language

Fuzzy Sets and Systems 34 (1990) 263-291 263 North-Holland

F M U F L : A F U Z Z Y M U L T I - P A R A D I G M L A N G U A G E

James B O W E N Department of Computer Science, North Carolina State University, Box 8206, Raleigh, NC 27695-8206, U.S.A.

Jianchu K A N G Department of Computer Science, Beijing Institute of Aeronautics, Beijing, People's Republic of China

Received January 1988 Revised March 1988

Abstract: Humans use a wide variety of formalisms to express themselves. In the course of a single exposition, a domain expert may use several modes of expression to present his expertise to a knowledge engineer. This, combined with the fact that building expert systems requires an iterative programming approach, and with the fact that much human expertise is couched in lexically imprecise terms, means that the trend in languages for knowledge engineering will be towards fuzzy multiparadigm languages. This paper presents a language which is the first step in this direction.

The main points made in the paper are: there is a distinction between declarative and imperative productions; the truth value of a fact asserted by an imperative production can be completely unrelated to the truth value of the condition part of the production; relative truth-values should not be the primary criterion when resolving conflicts between imperative productions.

Keywords: Expert systems; productions systems; lexical imprecision; knowledge engineering; conflict resolution.

1. Introduction

In expert system development , an iterative prototyping methodology [22, 25, 45] is usually used. This requires programming languages which support high p rogrammer productivity. One way of improving p rog rammer productivity is to reduce the amount of t ransformation that must be done when encoding the domain knowledge acquired f rom human experts. Programming languages must support something approaching the diversivity of expressive forms used by domain experts; hence, the recent trend towards mult i-paradigm languages [19, 23, 24, 27, 34, 39, 42, 49, 50, 51, 52, 55]. Fur thermore , much human expertise is couched in lexically imprecise terminology and efforts are being made to develop knowledge engineering tools for handling fuzziness [13, 20, 32, 33, 28, 46, 47, 48]. Thus, a trend towards fuzzy mult i -paradigm languages for knowledge engineering can be fairly confidently predicted. This paper presents a language, F M U F L , which is a first step in that direction.

F M U F L supports four p rogramming paradigms; the central paradigm is a forward-chaining imperat ive product ion system; the other three paradigms

0165-0114/90/$3.50 © 1990, Elsevier Science Publishers B.V. (North-Holland)

264 J. Bowen, J. Kang

support conceptual abstraction in the condition and action parts of the forward- chaining imperative productions. The language handles lexical imprecision by supporting fuzzy matching between condition patterns and facts in working memory. Although various fuzzy uni-paradigm languages have been described in the literature, FMUFL seems to be the first fuzzy multi-paradigm language.

In Section 2, the various types of production system paradigm are discussed. In Section 3, the non-fuzzy aspects of FMUFL are presented. In Section 4, fuzzy reasoning in FMUFL is described. In Section 5, the conflict resolution algorithm used in FMUFL is presented. In Section 6, FMUFL is compared with other fuzzy languages. The conclusions are presented in Section 7. The appendix gives an example program in FMUFL, an example which is referenced at several points in the paper.

2. Production systems

Production systems [12, 16, 22, 40] are often classified as either backward- chaining or forward-chaining [1, 25]. It is also useful, however, to classify them as either imperative or declarative. A declarative production, such a s 1

bachelor(X) if man(X) and unmarried(X) (1)

merely defines some fact in terms of a group of other facts. On the other hand, an imperative production, such as

when lucky(X) and untrue has_been_congratulated(X) then output "Congratulations" & X (2)

decrees that, under certain conditions, certain behaviour should be exhibited. This distinction between declarations of truth and directives of behaviour

deserves emphasis. Consider the following production, which specifies that a certain fact should be stored in the working memory when two other facts are already present:

when man(X) and unmarried(X) then store bachelor(X). (3)

This production should be contrasted with (1). Production (3) is imperative while (1) is declarative. In languages which only support imperative productions, such as OPS5 [12], 2 an imperative production might be used to implement the intent of

1 In this paper, FMUFL keywords are printed in bold-face. Tokens which start with capital letters are variables.

2 A language is 'procedural ' if it has the generic architecture characteristic of languages like Pascal, FORTRAN and BASIC. A language statement is ' imperative' if it expresses an order. These two adjectives are not synonymous. There are non-procedural languages which contain imperative statement types. OPS5 is one such language: it is non-procedural; but productions in OPS5 are imperative constructs. Unfortunately, some authors fail to recognise the difference between procedural and imperative, causing errors in language classification. Thus, although an imperative/ declarative dichotomy is meaningful, some authors mistakenly talk of a procedural/declarative dichotomy. Then knowing that OPS5 is non-procedural language, they mistakenly classify it as a declarative language.

Fuzzy multi-paradigm language 265

a declarative production, just as (3) could be regarded as implementing certain aspects of (1). But this should not obscure the crucial differences between declarative and imperative productions.

A declarative production is monotonic and has no side-effects: it merely determines the truth of some fact which is implicit within an existing body of assertions, without negating any of these premises. An imperative production, however, may be non-monotonic and may also have side-effects: as well as asserting new facts, it may also retract existing information - it could even retract one of the premises which activated it; furthermore, as well as manipulating a set of assertions it may perform input/output.

As a further illustration of the difference between declarative and imperative productions, consider the following:

when man(X) and unmarried(X) and woman(Y) and unmarried(Y)

then remove unmarried(X) and remove unmarried(Y) and store married(X,Y). (4)

Contrast this with (1). Production (4) is a state-change operator which retracts two old facts and asserts a new one; it specifies behaviour; it is imperative. Production (1) is not a state-change operator; it merely indicates a fact which is implicit in the existing state; it does not specify behaviour; it is declarative. Now contrast (4) with (3). Production (4) is an imperative production used for an imperative purpose; production (3) is an imperative production used for a declarative purpose. Production (4) presents an example of coherence between syntax and semantics; the syntax of (4) is suggestive of behaviour specification and the production actually does specify behaviour. Production (3) presents an example of incoherence between syntax and semantics. In a language which supports both declarative and imperative productions, (1) is preferable to (3) because there is a better match between syntax and semantics.

In production (3), an attempt is being made to use an imperative production to implement the operational semantics of a declarative production like (1). In fact, the attempt is inadequate; production (3) does not fully implement the semantics of production (1). Production (1) says that X is a bachelor if he is an unmarried man; implicit in this is the fact that if either of these conditions ceases to be true, X will no longer be a bachelor. To fully implement production (1) using imperative productions it is necessary to complement production (3) with the following two imperative productions:

when bachelor(X) and untrue unmarried(X) then remove bachelor(X). (5)

when bachelor(X) and untrue man(X) then remove bachelor(X). (6)

For example, if production (4) were to marry X, then production (5) would retract the characterization of X as a bachelor; also if, by some means, X were to cease being a man, production (6) would ensure that he was no longer treated as a bachelor.


It is sometimes mistakenly believed that backward-chaining is synonymous with declarative, and forward-chaining with imperative. It should be emphasized that this is not the case. In general, either backward- or forward-chaining may be used with declarative productions [1]. In backward-chaining, which is goal-driven, production (1) would be invoked whenever it is necessary to determine whether some entity is a bachelor. In forward-chaining, which is data-driven, production (1) would be invoked whenever we know that some entity is a man and is unmarried, regardless of whether or not we are interested in knowing that that particular entity is a bachelor. Although both forward- and backward-chaining are possible with declarative productions, in fact, declarative productions are usually backward-chained.

Imperative productions are almost always forward-chained [12]. Thus, if production (2) is forward-chained, it would be invoked whenever we know that some entity is lucky but has not yet been congratulated. Backward-chaining through imperative productions has rather abstruse semantics and is rarely done; consider, for example, how unclear are the semantics of backward-chaining through production (2).

The fuzzy reasoning literature contains many references to fuzzy production systems [31, 41, 53, 54]. To the extent that these systems are data-driven (rather than goal-driven), they may be viewed as forward-chaining. Furthermore, those systems which issue control outputs may be viewed as imperative. However they are different from the classical type of foward-chaining imperative production (FCIP) system.

The architecture typical of classical FCIP systems [12, 16] is shown in Figure 1. The working memory contains a body of facts which describe the current state of whatever system is being modelled by the FCIP program. The rule base contains an unordered set of FCIPs.

The interpreter executes the following three-phase recognise-act cycle: (a) Match: Compare the condition part, or left hand side (LHS), of each FCIP

with the assertions in working memory, collecting all instantiations of each satisfied FCIP into a conflict set. (An instantiation is a copy of an FCIP in which all LHS variables have been bound, by matching with values in working memory assertions.)

(b) Conflict Resolution: Select from among the instantiations in the conflict set a subset (in most languages the cardinality of this subset is one) of instantiations which, on the basis of certain criteria, appear the most relevant to the current

Working memory

Rule base

Interpreter

Fig. 1. Typical architecture of classical FCIP languages.


situation in working memory. If no such instantiation can be found, then halt. (c) Act: Perform the actions specified by the instructions in the action part, or

right hand side (RHS), of the selected FCIP instantiation(s). Then go back to phase (a).

In a classical FCIP system, therefore, only a subset of the productions fire on each cycle; in most systems only one production fires on each cycle. On the other hand, in a fuzzy production system [56], all productions can be considered as firing during each cycle, but with strengths ranging along a continuum from 'not at all' to 'completely', rather than in the all or nothing fashion characteristic of classical FCIP systems.

Uni-paradigm FCIP languages, as well as multi-paradigm languages which include the FCIP paradigm, have been used to implement some of the most significant Artificial Intelligence applications [21, 30, 36, 37, 38, 39, 43]. However, classical FCIP languages make no provision for handling lexical imprecision. Thus, for example, there is no notion of fuzziness in such languages as OPS5 [12, 18], OPS83 [191, ART [23], KEE [24], YAPS [2, 3], YES/L1 [39], or YES/OPS [44].

It is necessary to note this distinction between fuzzy production systems and FCIP systems. The language described in this paper, FMUFL, bridges the gap between classical FCIP languages and fuzzy production systems. Although FMUFL is a multi-paradigm language, the FCIP paradigm is central to the language. FMUFL is also a fuzzy language in that it supports the use of lexical imprecision. Forward-chaining imperative production systems which handle fuzziness are relatively new; the only other systems known are the serial and parallel versions of FLOPS [13, 46, 47, 48].

3. Crisp reasoning in FMUFL

FMUFL is an extension of an earlier multi-paradigm language, MUFL [7, 8, 9], to incorporate fuzzy reasoning. MUFL, which runs on both IBM PCs and Vaxen, has been used to develop several expert systems, including a large system for brickwork cladding design [11, 15]. FMUFL, at present running only on Vaxen, has only been used in small-scale systems; the implementation needs to be further optimized before it will be etlicient enough for large-scale applications.

FMUFL's top-level architecture is the three-part architecture (Figure 1) typical of FCIP systems [16, 18, 25]; at the top level, a program written in FMUFL consists of a set of facts in working memory and a set of FCIPs. But the language also supports three other formalisms: declarative productions (which are backward-chained), procedural programming and functional programming. The language incorporates these other formalisms as ancillary to forward-chaining imperative productions; they are used to support top-down design and conceptual abstraction in FCIPs [10].

Consider the following example, which introduces the multiple paradigms supported by the .language and illustrates how they support conceptual abstrac-


tion. There is the following collection of base-level facts in F M U F L ' s working memory: 3

male(john). female(may) . adult(john). adult(may). unmarr ied(john) . unmarr ied(may) . l ikes(may,john). l ikes(john,may). monthly_salary(j ohn,2000). monthly_salary(may,3000).

(7)

If we need a demon which marries two unmarr ied adult friends of opposite sexes whose joint annual salary exceeds 30 000 dollars, we could achieve this with the following FCIP in FMUFL.

when male(X) and adult(X) and unmarried(X) and female(Y) and adult(Y) and unmarried(Y) and l ikes(X,Y) and likes(Y,X) and monthly_salary(X,S1) and monthly_salary(Y,S2) and 12 * ($1 + $2) > 30 000

then remove unmarried(X) and remove unmarried(Y) and store marr ied(X,Y) . (8)

However , it would be much bet ter if we could use higher level concepts in the condition and action parts of the FCIP, as follows:

when bachelor(X) and spinster(Y) and fr iends(X,Y) and jo int_annual_salary of (X and Y) > 30 000

then marry X with Y. (9)

To support the condition part of this FCIP, we would define a collection of declarative productions and functions. The declarative productions would be as follows:

bachelor(A) if man(A) and unmarr ied(A) . man(A) if male(A) and adult(A). spinster(A) if woman(A) and unmarr ied(A) . woman(A) if female(A) and adult(A). fr iends(A,B) if l ikes(A,B) and l ikes(B,A). (10)

3 The syntax of certain parts of FMUFL ressembles that of Edinburgh-syntax Prolog [14]. In this, it differs from other FCIP languages, which generally have a LISP-like syntax [2, 3, 18, 23]. Base-level facts in FMUFL's working memory are similar to those in Prolog database. Since Prolog structured terms are more general than LISP lists, working memory base-level facts in FMUFL are more general than those in FCIP languages which are derived from LISP. Some [18] of these LISP-derived FCIP languages, in fact, do not even support working memory entries that are as general as LISP lists.


The functions would be:

the joint_annual_salary of (A and B) is annual_salary of A + annual_salary of B. (11)

the annual_salary of A is 12 * M if monthly_salary(A,M).

In (10) and (11) higher level concepts, such as bachelor, or joint annual salary, are defined in terms of lower level concepts such as male, adult, and unmarried, or annual and monthly salaries. Concepts are defined in an orderly, t o p -d o w n way, using hierarchies of declarative productions and function definitions.

The action part of the FCIP in (9) would be supported by the following procedure :4

to marry A with B do (remove unmarried(A) and remove unmarried(B) and

store married(A,B)) . (12)

In this particular instance, we do not need a hierarchy of procedures, but such hierarchies can be used to develop the action part of FCIPs in a disciplined top-down fashion.

In passing, and with a backward glance to the earlier discussion on declarative versus imperative productions, it should be noted in F MU F L only FCIP action parts, or procedures (which are called by FCIP action parts), are able to modify the contents of working memory; declarative productions does not actually assert their conclusions in the working memory.

4. Lexical imprecision in FMUFL

4.1. Fuzzy sets

Fuzzy reasoning in FMUFL is based on both finite and infinite fuzzy sets. Finite sets may be described by exhaustively listing those elements of the universe of discourse which have non-zero degrees of membership: the membership function is described by listing every mapping involved. This cannot be done for infinite sets. Many infinite fuzzy sets, however, may be approximated by easily described membership functions. One way of describing these membership functions is by using standardized S or ~ functions with adjustable parameters [17]; another approach, based on linear interpolation, is to use I-type sets [5]. At present, this latter is the only method of describing infinite fuzzy sets which is supported by FMUFL.

I-type sests are used to represent concepts such as tall. Here , the universe of discourse, U, is some segment of the real number line representing heights, and tall is a label for a fuzzy subset of U. If the membership degree in the fuzzy set of

4 As mentioned earlier, many of the ideas present in Edinburgh-syntax Proiog have been adopted in FMUFL. One of these is the feature of allowing programmers to define their own syntactic sugar. Strictly, this procedure definition ought to read "to marry(with(A,B)) do ..." but by defining 'with' as an infix operator and 'marry' as a prefix operator, the procedure definition can be written as shown here. Operator definitions are widely used in the example program provided in the appendix.


two heights is known, the membership degree of some intervening height can be interpolated.

Finite sets are used to represent concepts such as happy or likes. Here, the universe of discourse, U, could be some set of people. Happy is a label for some fuzzy subset of U and likes is a label for some fuzzy subset of U × U. Membership degrees cannot be interpolated; each fuzzy subset must be specified by exhaustively listing its support points.

FMUFL also provides a type of mechanism, called a semantic relationship, which can be used to ease the burden of defining fuzzy sets. If a fuzzy set, be it an I-type set or a finite set has been explicitly defined to represent some concept, other fuzzy sets which represent related concepts can be declared by defining semantic relationships which specify how the concepts are related.

4.1.1. 1-type sets 1-type sets are declared by means of tables. For example, the fuzzy concept tall

may be defined in a table as follows:

table(tall, person, height, [48,84], [[60,0], [64,0.1], [69,0.8], [72,1]]). (13)

In this example, the first argument, tall, is the label of the fuzzy set defined by the table; the second and third arguments, person and height, specify the class of entity and the attribute of these entities for which the word tall may be used as a fuzzy value; the fourth argument [48, 84] indicates the universe of discourse, of which the fuzzy set tall is a subset. The fifth argument is the meaning of the concept tall. It consists of a sequence of pairs of numbers, ordered by the first number in each pair; each pair of numbers represents a member of the fuzzy subset, with the first number being a value in the universe of discourse and the second number being the membership degree of the first number in the fuzzy subset.

4.1.2. Finite sets Finite sets are declared by exhaustive listing the members of the set, giving the

degree to which each is a member of the set. For example, the following defines the fuzzy set happy:

happy(mary) with truth 0.7 happy(tom) with truth 0.5 (14) happy(john)

which is a fuzzy subset of some universe of discourse, U, while the following defines the fuzzy relationship likes:

likes(mary, fred) with truth 0.9 likes(helen, tom) with truth 0.6 (15) likes(john, mary) with truth 0.8

which is a fuzzy subset of U x U. In examples (14) and (15), the labels of the finite fuzzy sets being defined were

predicates of facts stored in the working memory; these entries are similar to


fuzzy facts in an FPROLOG database [32]. However, in FMUFL, fuzzy set labels may also be fact arguments. For example, the information in (14) could also be defined as

state_of_mind(mary, happy) with truth 0.7 state_of_mind(tom, happy) with truth 0.5 (16) state_of_mind(john, happy)

while the information in (15) could also be represented as

relationship_between(mary, fred, cordial) with truth 0.9 relationship_between(helen, tom, cordial) with truth 0.6 (17) relationship_between(john, mary, cordial) with truth 0.8

in which cordial is used as a fuzzy set label.

4.1.3. Semantic relationships It is not necessary for the programmer to provide tables or lists of facts defining

the meaning of all primary fuzzy concepts used in a program. He can define some of them by expressing their semantic relationships to those concepts for which tables or facts have been provided. FMUFL supports three types of semantic relationships: antonyms, base-synonyms and modified-synonyms.

Suppose, for example, that the concept tall is defined as in (13) above. If short is now defined as an antonym of tall,

antonym(tall, short), (18)

FMUFL will treat the concept short as equivalent to not tall. That is, it will treat short as if it were defined by the following table:

table(short, person, height, [48,84], [[60,1], [64,0.9], [69,0.2], [72,0]]). (19)

The base_synonym relationship is used to equate any number of primary terms. For example, if we explicitly define

base_synonym([little, small, diminutive]) table(little, number, magnitude, [1, 10], [[1,1], [3,0.6], [4,0.2], [6,0]]) (20)

then we have also implicitly defined

table(small, number, magnitude, [1,10], [[1,1], [3,0.6], [4,0.2], [6,0]]) table(diminutive, number, magnitude, [1,10], [[1,1], [3,0.6], [4,0.2], [6,0]]). (21)

The modified synonym relationship is used to equate any number of primary terms to a non-primary linguistic value. For example, given the definitions in (20), if we define

modified_synonym([tiny, minute, very small]) (22)

that is the same as defining the following tables:

table(tiny, number, magnitude, [1,10], [[1,1], [3,0.36], [4,0.04], [6,01] ) table(minute, number, magnitude, [1,10], [[1,1], [3,0.36], [4,0.04], [6,0]]). (23)


4.2. Representing fuzziness in the working memory

A fuzzy proposition may be either criterion-referenced or norm-referenced. Criterion-referenced propositions are those like

John is quite tall

in which the fuzzy concept, in this case 'tall', is treated as a fuzzy subset of the real number line, the points on the number line being values of an underlying attribute, in this case 'height', which is amenable to interpolation. When determining the compatibility between an entity and a fuzzy descriptor, the fuzzy subset of the real number line is used as a criterion with which the entity's attribute value can be compared.

Norm-referenced propositions are those like

John is quite happy John quite likes Mary

in which the fuzzy concepts cannot be treated as fuzzy subsets of values for an associated attribute; for example, there is no convenient attribute which is related to 'happy' in the way that 'height' is related to 'tall'. Concepts like 'happy' and 'likes' must be fully specified through exhaustive exemplification, rather than partially specified with the remaining support points being determined by interpolation.

In FMUFL, norm-referenced fuzzy propositions are represented as working memory entries that are treated as members of finite fuzzy sets. Thus, for example, the working memory entries

happy(john) with truth 0.7 (24) state_of_mind(john, happy) with truth 0.7

either of which could be used to state how happy John is, are treated as specifying the membership degree of john, or his state of mind, in the finite fuzzy set happy. Similarly, the working memory entries

likes(john, mary) with truth 0.8 (25) relationship_between(john, mary, cordial) with truth 0.8

either of which could be used to describe the relationship between John and Mary, are treated, respectively, as specifying the membership degree of the pair (john, mary) in the finite fuzzy set likes or of the relationship between john and mary in the finite fuzzy set cordial.

These norm-referenced working memory facts can be used, with semantic relationship definitions, to match condition patterns such as

happy(Who) state_of_mind(john, sad) likes(john, Who) (26) relationship_between(john, mary, very unfriendly).

which represent norm-referenced fuzzy queries. This type of fuzzy matching will be described in Section 4.6.1.


While norm-referenced propositons and queries are handled with finite fuzzy sets, criterion-referenced information is handled using I-type fuzzy sets. Thus the proposition

height(john, person, 71). (27)

can be used, in conjunction with the I-type set defined by the table in (13) to answer queries such as

height(john, person, tall) (28) height(john, person, very short).

This type of fuzzy matching will be shown in Section 4.6.2.

4.3. Fuzziness in forward-chaining imperative productions

The condition part of an FCIP can contain fuzzy queries and its action part can assert/retract fuzzy propositions to/from the working memory. For example, consider the following FCIP:

when likes(X,Y) and height(Y,person,tall) (29) then store likes_tall_person(X,Y) qualified.

This states that whenever it is possible to find a pair of entities which satisfy the composite fuzzy query

likes(X,Y) and height(Y, person, tall) (30)

then it should be asserted in the working memory that the pair of entities belong to the finite fuzzy relation likes_tall_person, the membership degree being equal to the truth-value of the composite fuzzy query.

The form of store procedure used in (29) gives the assertion the same truth value as that computed for the condition part of the FCIP; this is the same as in FLOPS [13, 46, 47, 48]. There are two alternatives in FMUFL, however. If the keyword qnalified is absent, the assertion is given a truth value of 1.0, by default. If the keyword qualified is replaced by the phrase with truth and a number in [0,1], the number quoted is assigned as the truth value.

In fact, the form of store used in (29) is rarely used in practice. Normally, the implication implemented by (29) would be expressed by a fuzzy declarative production (see (33) below), just as the crisp implication implemented by (3) is better expressed as the crisp declarative production (1). If FCIPs are used correctly, to express directives rather than to implement implications which are better stated declaratively, it is frequently the case that the action part of an FCIP will assert facts whose truth values are unrelated to the truth value of its condition part. Suppose, for example, that a demon is required to imprison somebody who is evil, where evil is a fuzzy concept. This demon could be implemented as the following FCIP:

when evil(X) then store in_prison(X). (31)


Since being imprisoned is a crisp concept, the truth value of the fact asserted by this FCIP is unity, while the truth value of the LHS of the FCIP could be less than that. The truth value of the LHS need only be high enough to exceed the threshold required for entry into the conflict set of instantiated FCIPs; this threshold is programmable but the default value is 0.5.

In (31), the truth value of the fact asserted by the FCIP, unity, could be higher than the truth value of the FCIP instantiation; but the opposite can also be true. Consider the following FCIP, which asks the user how happy some entity is and then notes this in working memory.

when need_to_know_how_happy_is(X) then output "On a scale of 0-1, how happy is" & X & "?" (32)

and input Degree and store happy(X) with truth Degree.

Here, the LHS side refers to a crisp condition, having a truth value of 1, but the fact asserted by the RHS could have a truth value less than that. Note also the extent of the decoupling between the truth value of the LHS and the truth value of the assertion: the truth value of the assertion is determined by the user who could be completely unaware of the internal workings of the program he is using.

4.4. Fuzziness in declarative productions, procedures and functions

A declarative production in FMUFL is similar to a non-unit clause in FPROLOG [32]. Both the antecedent and consequent of a declarative production can reference fuzzy concepts. Fuzzy consequents must be norm-referenced, although fuzzy antecedents may be either norm- or criterion-referenced. The truth value of the antecedent is used as the membership grade of the consequent; consider, for example, the following declarative production:

likes_tall_person(X,Y) if likes(X,Y) and height(Y,person,tall) (33)

which specifies the implication implemented in FCIP (29) above. Fuzziness in procedures is the same as in the action part of FCIPs. There can

be fuzzy matching between the working memory and boolean expressions in conditional and iterative constructs. Procedures can assert/retract fuzzy facts to/from working memory.

In the current version of FMUFL, fuzziness has not yet been extended to functions.

4.5. Fuzzy reasoning in the FMUFL run-time support system

The most important part of the FMUFL run-time system is the FCIP interpreter, since this is the central paradigm of this multi-paradigm language. This interpreter, like those for most FCIP languages, executes the three phase recognise-act cycle described in Section 2. In FMUFL, all three phases are affected by the presence of fuzziness. During the Match phase, the interpreter must perform fuzzy matching between facts in working memory and pattern


condition queries from the condition part of FCIPs or from the antecedent part of declarative productions. During Conflict resolution, the relative truth-value of competing FCIP instantiations must be taken into account, as well as the other conflict resolution criteria normally used in FCIP languages. During the Act phase, the interpreter may have to perform fuzzy matching between working memory facts and pattern condition queries from conditional or iterative constructs in the action part of the fired FCIP or in procedures called by the action part of the fired FCIP.

FMUFL's approach towards fuzzy pattern matching will now be described. The approach towards conflict resolution will be described in Section 5.

The FMUFL interpreter can do both exact and fuzzy pattern matching. When trying to answer a query, it first tries to answer the query by exact matching; only when this fails does it resort to fuzzy pattern matching. During fuzzy pattern matching, FMUFL needs to apply two sets of rules: matching rules and translation rules. Matching rules govern the matching of a query with the facts that can provide the information necessary for determining the truth-value of the query. Translation rules yield the truth-value of a modified or composite proposition from the truth-values of its constituents.

4.6. Matching rules in FMUFL

4.6.1. Matching a norm-referenced query As a simple example, assume that working memory contains a norm-referenced

fuzzy relation as follows:

appearance(helen, very beautiful) appearance(rose, not very beautiful) with truth 0.7 (34) appearance(mary, beautiful) with truth 0.8.

Consider the query

appearance(mary, beautiful) (35)

which illustrates the simplest kind of matching. A match is made with the third tuplet in the relation, the match being given a truth value of 0.8.

However, more often than not, more complicated situations occur. Suppose that the query is

appearance(rose, beautiful). (36)

In this case, a match would be made with the second tuplet of (34), the truth value of the match being derived from that for the tuplet in the relation, 0.7, using the definitions of the hedge very and the modifier not.

In general, an argument of a norm-referenced query can be matched with the corresponding argument in a working memory fact if the arguments are comparable (i.e., they belong to the same term set). Two linguistic values belong to the same term set [58] if they contain the same primary term (negated or modified by various hedges) or if one can be derived from the other by following a chain of semantic relationships.


Thus, for example, FMUFL can match the following queries corresponding facts (Q indicates a query, K a working memory fact):

Q: appearance(rose, K: appearance(rose,




beautiful) not beautiful) with truth 0.2

very beautiful) beautiful) with truth 0.8

not very beautiful) fairly beautiful) with truth 0.7

not beautiful) ugly) with truth 0.2

with the

(37)

(38)

(39)

(40)

For matches (37) through (39), the primary terms in the linguistic values being matched are the same, but the hedges are different. However, for match (40), the primary terms are different. Whenever the primary terms used in two linguistic values are different, a match can be made if some series of semantic relationships make it possible to transform the primary term used in the query into that used in the working memory fact. For example, a relationship such as

antonym(beautiful, ugly) (41)

makes possible a one-step transformation in (40) above. The truth-value of a fuzzily matched norm-referenced query can be obtained by

applying the translation rules, discussed in Section 4.7, to the truth-value of the matched fact.

4.6.2. Matching a criterion-frequency query Suppose that the concept tall is represented by the I-type fuzzy set defined in

(13) and that relation height is defined as follows:

height(fred, person, 72) height(peter, person, 74) height(jill, person, 66) height(tom, person, 67) (42) height(john, person, 69) height(jack, person, 71) height(mary, person, 51)

Consider the query

height(john ,person ,tall). (43)

The system determines that the truth-value of this query is equal to the membership degree of John's actual height, 69 inches, in the fuzzy set tall. In the table (13) which defines this fuzzy set, 69 is specified to have membership degree 0.8, so that is the truth-value of the query.

Generally speaking, however, the membership grade of the particular point in the universe of discourse in which we are interested will not be explicitly given in the table. In that situation, since all tables in FMUFL are I-type, FMUFL uses


linear interpolation or extrapolation. For example, with table (13), the match

Q: height(X, person, tall) K: height(tom, person, 67) (44)

would cause variable X to be bound to tom; the truth value of the query would be 0.52, derived by interpolation onto 67 from the values 0.1 and 0.8, which correspond, respectively, to the heights 64 and 69 inches.

FMUFL uses domain specifications to ensure that it uses the correct table when matching criterion-referenced queries. For example, suppose that there was, in addition to table (13), a table which specified the meaning of the word tall in the context of building heights:

table(tall, building, height, [60, 1000], [[120,0], [240,0.4], [480,0.7], [720,1]]). (45)

Then, when doing the match

Q: height(fred, person, very tall) K: height(fred, person, 72) (46)

FMUFL would have two alternative definitions for tall and would use the domain specfication, person, to choose the table in (13) rather than that in (45).

4.7. Translation rules in FMUFL

In Zadeh's fuzzy logic FL [58] there are four categories of translation rule: * modification rules, * composition rules, * quantification rules, * qualification rules. The form of fuzzy logic supported by FMUFL differs from FL in several ways.

Among these differences are that FMUFL does not support fuzzy quantification or fuzzy truth qualification. Thus, the translation rules in FMUFL, which yield the truth-value of a query from those of the related fact(s), belong to only the first two of Zadeh's four categories.

4.7.1. Modification rules in FMUFL FMUFL supports the three modifiers not, very and fairly. These are interpr-

eted as the operations complementation, concentration and dilation, respectively. For example, in match (37), FMUFL obtains the truth-value of the norm- referenced query by complementing the truth-value of the matched fact. Since the membership grade of Rose in the fuzzy set not beautiful is 0.2, her membership in the fuzzy set beautiful must be 1-0.2; thus, the truth-value of the query is 0.8. Similarly, in match (38), concentration is used, giving a truth-value of 0.64, which is 0.8 squared. In match (39), dilation concentration and complementation are all used.

If any semantic relationships were involved in matching a query and a fact, the set of modifications induced by these semantic relationships are used to calculate


the truth-value of the query. To calculate the truth-value of the norm-referenced query in (40), the antonym relationship between ugly and beautiful given in (41) is used.

FMUFL handles a criterion-referenced query in a similar way, except that a table is involved. Consider the query

height(john, person, very tall), (47)

the working memory fact

height(john, person, 69), (48)

the semantic relationship

antonym(tall, short), (49)

and the table

table(short,person,height, [48,84], [[60,1], [64,0.9], [69,0.1], [72,0]]). (50)

The truth value of (47) is equal to the membership grade of the height 69 inches in the fuzzy set very tall. The membership of 69 in the set short is 0.1 so, based on (49), the membership of 69 in the fuzzy set tall is 0.9. Then, using concentration, the membership grade of 69 in the fuzzy set very tall is 0.81.

4.7.2. Composition rules in FMUFL The most commonly employed compositions, conjunction and disjuntion, are

supported by FMUFL. It also supports a syntactically similar form of negation, with the unary operator untrue.

Conjunction and disjunction are implemented using the min and max operators. FMUFL uses the 'closed world assumption': it is assumed that FMUFL knows all there is to know about its world. Thus, for example, if FMUFL is trying to evaluate the query

health(john, good) (51)

and there is no entry in the database which can be matched, either exactly or fuzzily, with this query, then it is deemed that the query is false and it is given a truth-value of 0.0. This affects the handling of negated queries. Thus, for example, in the same situation, the following query would be given a truth-value of 1.0:

untrue health(john, good) (52)

The truth-value of the consequent of a declarative production is equal to the overall truth-value of the antecedent, which is derived, using the composition rules, from the truth-values of the individual queries in the antecedent. For example, consider the declarative production

likes_strong_person(X, Y) if likes(X, Y) and untrue size(X, big) and (height(Y,person,very tall)

and weight(Y,person,very heavy) or is_intelligent(Y)). (53)


Assume that all the constituent conditions in the antecedent are satisfied, with the variable instantiations and truth-values shown below:

likes_strong_person(mary, john) if likes(mary, john) with truth 0.8 and untrue size(mary, big) with truth 0.7 and (height(john,person,very tall) with truth 0.64

and weight(john,person,very heavy) with truth 0.6 or is_intelligent(john) with truth 0.7). (54)

By applying the composition rules to the truth-values of the antecedent conditions, that is,

0.8 ^ 0.7 A ((0.64 ^ 0.6) v 0.7) = 0.7, (55)

the overall truth-value of the consequent is derived as

likes_strong_person(mary,john) with truth 0.7. (56)

The calculation of the overall truth-value of a FCIP instantiation is the same as that for a declarative production. The role played in conflict resolution by the overall truth-value of an FCIP instantiation will be discussed in the next section.

5. Conflict resolution in forward_chaining imperative production systems

Usually, more than one FCIP is satisfied on any one cycle of an FCIP system and frequently some of these FCIPs may have several instantiations. A conflict- resolution strategy is a coordinated set of principles for selecting, among competing FCIP instantiations, a subset to be executed. In most FCIP systems, only one FCIP instantiation is executed on each cycle, although there are some systems which may execute several [47].

Conflict resolution is of vital importance in a forward-chaining imperative production system because it influences two crucial aspects of the system [12, 35]: its sensitivity and its stability. A forward-chaining imperative production system that is responsive to the demands of its environment is said to display sensitivity. One that is able to maintain continuity in its behaviour is said to display stability [35]. A system should be sensitive to the contents of its working memory; it should also be responsive not just to the contents of, but to changes in, its working memory. Furthermore, an FCIP system interpreter should be sensitive to its own state, as well as to the state of the working memory; for example, if there is some state information available which indicates that the system is about to enter an infinite loop, it is highly desirable that the interpreter take account of this information and prevent looping.

FMUFL's conflict resolution strategy is based on that of MUFL, the crisp language from which it is derived. That strategy is, in turn, based on the OPS5 [12, 18] conflict resolution strategy and comprises the following four principles or 'sieves', applied in the order given:

* refractoriness, * recency, * specifity * arbitrary choice.


Refractoriness is a principle which dictates that an instantiation should be removed from the conflict set if it has fired on a previous cycle and if it has been present in the conflict set on each cycle since it last fired. Recency specifies that, of the instantiations remaining in the conflict set, all should be removed except those which match the most recently asserted fact of all those facts which are matched by any instantiation in the conflict set. Specificity dictates that, of the remaining instantiations, preference should be given to those with the greatest number of condition elements. Arbitrary choice is only used if the previous 'sieves' have failed to reduce the conflict set down to one instantiation: an instantiation is chosen at random from among those remaining.

But the conflict resolution strategy in a fuzzy language like FMUFL must also consider the relative truth-values of competing instantiations; the truth-value principle would specify that preference be given to instantiations with the highest truth-value. So, in designing FMUFL, it was necessary to determine the place of the truth-value principle in its conflict-resolution strategy. These were five possible positions, marked (a) through (e) below:

(a)--~

refractoriness

recency (c)

specifity (d)--~

arbitrary choice (e)*-~

Position (a) was rejected since the refractoriness criterion ought to be first because it protects the system from infinite loops. Arbitrary choice should be the principle of last resort, so position (e) would be pointless.

Position (b) was rejected, based on the following reasoning. The truth-value principle focusses on the compatibility between the state description in working memory and the state description in the LHS of an instantiation. In this respect, it is similar to the specificity principle and, like the specificity principle, contributes to the stability of the system rather than its sensitivity. Since the recency principle contributes to the sensitivity of the system, which is more important than stability, recency ought to precede truth-value in conflict resolution.

There remained, therefore, the choice between positions (c) and (d). Position (d) was chosen in order to meet a primary aim in the design of FMUFL; this was to ensure that methodologies which have evolved for programming in crisp FCIP languages should also be usable in FMUFL.

The most important such methodology is the idea of task oriented programming [12], in which FCIPs are organised into a hierarchy, thus imposing structure on imperative knowledge which is expressed as FCIPs. This approach was


originally used in the development of the influential R1/XCON program [36]. s In task oriented programming, each FCIP is associated with a particular task in a hierarchy and has, as its first condition element, a test for the presence in working memory of a flag which indicates that the task is active. Task-activation flags are asserted into and removed from working memory in much the same way as activation records are pushed onto and popped from a stack during the execution of a program written in a traditional block-structured procedural language. An appendix to this paper contains a simple example program written in FMUFL, based on this task oriented methodology.

In order to support the task oriented programming methodology, specificity must be used before truth-value in conflict resolution; the reasoning behind this will be described in detail in a future paper. Thus, in FMUFL the conflict resolution strategy consists of the following five principles, used in the order shown:

* refractoriness, * recency, * specifity, * truth-value, * arbitrary choice.

6. Comparisons

There is a growing number of uni-paradigm languages based on the notion of lexical imprecision, including FUZZY [29], REVEAL [26], FRIL [4, 5, 6], FPROLOG [32], SPII-1 [33], SPII-2 [28] and FLOPS [13, 46, 47, 48]. As yet, however, there are no fuzzy multi-paradigm languages besides FMUFL. There are similarities, and differences, between the various paradigms supported by the uniparadigm languages just listed and those supported by FMUFL. For example, declarative productions in FMUFL are similar to non-unit clauses in FPROLOG, rewrite rules in FRIL and inference rules in SPII.

Apart from FMUFL, the only language which supports fuzzy forward-chaining imperative productions seems to be FLOPS. There are crucial differences, however, between the forms of FCIP supported by these two languages, differences which affect the types of application for which they may be used.

The form of assert action available in the RHS of a FLOPS production is similar to the store ... qualified verb used in (29). That is, the truth-value of an assertion made by the RHS of a FLOPS production is linked to the truth-value of the production's LHS; there seems to be no way of avoiding this linkage [13]. However, in FMUFL this decoupling is possible; see (31) and (32) above. It would seem from this that FLOPS is intended only for applications which require ill-structured forward-chaining inference. While this type of application may be addressed using FMUFL, FMUFL may also be used, and indeed is primarily

5 In [8, 9] it is shown how the task-oriented approach to programming FCIP systems can be taken even further than shown in [12].


intended, for partly-structured imperative applications. These applications, an example of which is given in the appendix, require the ability to assert facts whose truth values are unconnected with the truth value of the FCIP that is causing the facts to be stored.

Consider, for example, the following FCIP, which is taken from the program in the appendix:

when doing(add_cheap_complementary_items) and selected(list) and bread in List and untrue(butter in List) (57) and price(butter,food,cheap)

then add butter to_selection.

This FCIP is a demon which adds butter to a grocery list containing bread without butter, provided butter is cheap. An instantiation of this FCIP, showing instantiated variables and truth values, might be:

when doing(add_cheap_complementary_items) with truth 1 and selected([tea,bread]) with truth 1 and bread in [tea,bread] with truth 1 and untrue(butter in [tea,bread]) with truth 1 (58) and price(butter,food,cheap) with truth 0.67


The overall truth value of the instantiation is 0.67 but, when the procedure 'add', which is defined as follows:

to add Item to_selection do (remove selected(List) and

make Newlist = Item plus List and store selected(Newlist)). (59)

is executed, the effect is to store the fact

selected([butter,tea,bread])

with a truth value of 1. It seems that this decoupling of truth values, between 0.67 for the FCIP and 1 for the resulting assertion, cannot be achieved in FLOPS.

Another difference exists between these two languages, between the ways in which they use truth values in conflict resolution. This difference deserves emphasis here because it, also, affects the types of application which may be addressed by these languages.

There are actually two versions of FLOPS: one fires rules sequentially and the other fires them in parallel. In the sequential version [13], the instantiations in the conflict set are ranked using truth-value as the primary ranking criterion. In the parallel version [47], all fireable instantiations in the conflict set are fired together; if more than one of these wants to modify the same working memory fact, the mediation is based on fuzzy monotonicity.


The differing approaches taken to conflict resolution in FMUFL and FLOPS means that these two languages are suitable for different classes of application. The approaches taken to conflict resolution in FLOPS mean that the language cannot be used to write partly-structured imperative programs, that is programs based on the task oriented methodology which is described in the previous section and which is used in the example program provided in the appendix. In FMUFL, however, the conflict resolution strategy was designed expressly to ensure that task oriented programming could be supported. Support for task oriented programming requires that truth-values be used to resolve conflicts only after all other criteria, except arbitrary choice, have been tried. The parallel version of FLOPS cannot, of course, be used for task oriented programming which requires that rules be fired sequentially. The sequential version of FLOPS cannot support task oriented programming because the truth-value principle is the first criterion used in its conflict resolution strategy.

Consider, for example, the following imperative productions from the program in the appendix:

when doing(remove_very_expensive_items) and selected(List) and Item in List and price(Item,food,very expensive)

then take Item out_of_selection. (60)

when doing(remove_very_expensive_items) then replace doing(remove_very_expensive_items) by

doing(add_cheap_complementary_items). (61)

The first FCIP, (60), is intended to remove all very expensive items from the grocery list whose price has a degree of membership in the fuzzy set very expensive that exceeds the threshold for entry into the conflict set. The second FCIP, (61), terminates the task of removing very expensive items from the grocery list, by replacing the activation flag for this task with a flag activating a different task.

The relationship between these two FCIPs illustrates why relative truth-values cannot be used as the first conflict resolution criterion in languages which are intended to support task oriented programming. If relative truth-values were used as the first conflict resolution criterion, production (61) would dominate all instantiations of production (60) except for those cases where the grocery list contained items whose prices had a membership degree of unity in the fuzzy set very expensive. For example, the sample interaction given in the appendix could not occur, because production (60) would be unable to remove caviar from the list of selected groceries.

Task-oriented programming is as important to forward-chaining imperative production languages as structured programming concepts are to procedural programming languages. It is the methodology recommended for partly- structured imperative problems, in text books on programming in FCIP languages such as OPS5 [12]. FMUFL allows the programmer to follow this methodology in


programming partly-structured problems which involve fuzzy concepts. The approach to conflict resolution adopted in FLOPS means that this language cannot be used in programming partly-structured problems. FLOPS' conflict resolution strategy and the form of assert action which it provides indicate that the language is primarily suitable for, and was intended for, ill-structured forward-chaining inference problems.

7. Conclusions

The long-term trend in programming language development has been towards languages which support expressive forms that in some way approximate those used by humans. This was the motivation behind the sequence that has led from machine code, through assembly language, on to FORTRAN, Pascal, Lisp and Prolog. This was also the motivation behind the development of fuzzy reasoning, which is concerned with handling the lexical imprecision found in human discourse.

Humans use a wide variety of formalisms. In the course of a single exposition, a domain expert may use several modes of expression to present his expertise to a knowledge engineer. This, combined with the fact that building expert systems requires an iterative programming approach, and with the fact that much human expertise is couched in lexically imprecise terms, means that the trend in languages for knowledge engineering will be towards fuzzy multi-paradigm languages. FMUFL, the language presented in this paper, is the first step in this direction. The central paradigm provided by the language is a forward-chaining imperative production system; this is supplemented by a declarative production system, procedural programming and functional programming. Fuzzy concepts can be processed using the first three of these paradigms.

Apart from being the first fuzzy multi-paradigm language, FMUFL is one of only two languages which support fuzzy forward-chaining imperative productions. FMUFL differs from FLOPS, the only other such language, however, in the form of assert action which it provides and in the way in which it handles truth values in conflict resolution.

Although imperative productions can be used to implement the operational semantics of declarative productions, the chief purpose of imperative productions is to serve as state-change operators. When an imperative production is acting as a state-change operator, there need not be any connection between the truth-value of the production's condition part and the truth values of the facts asserted by its action part. In FLOPS, this decoupling does not seem to be possible; in FMUFL it is.

Partly-structured imperative problems are a broad class of problem which include some of the most significant AI applications [36, 12]. When this class of problem involves lexical imprecision, in conflict resolution the relative truth values of imperative production instantiations should only be used as a deciding factor when all other criteria, apart from arbitrary choice, have been used. This is the case in FMUFL, but not in FLOPS.


Appendix

This appendix presents an implementation in FMUFL of the grocery configuration problem presented by Winston [57], modified to include lexical imprecision. The user of this program specifies a list of groceries which he intends to buy. The program checks this list, amending it as necessary, and packs the groceries into bags, taking care to avoid over-filling a bag and to avoid crushing light items by placing them underneath heavy items.

Consider, for example the following interaction with the program:

INITIAL SELECTION: (one item at a time; to end type "complete") Item please: potato_chips. Item please: bread. Item please: caviar. Item please: complete.

FINAL CONFIGURATION: (top item in a bag listed first) bag2 contains potato_chips bread bagl contains butter jam pepsi.

The user selected three items, but one of these, caviar, was removed because it was very expensive, while pepsi was added to complement potato_chips, and butter and jam were added to complement bread. When the groceries were packed, the heavy bottles of pepsi and jam were placed at the bottom of a bag, to avoid crushing other items.

Task-oriented programming is used in this program: working memory facts with predicate doing and arity 1 are used as task activation flags. There are four top-level tasks: getting the user's initial selection of groceries; amending this selection; packing the groceries into bags; printing out the final configuration of groceries and bags. The amend_selection task has two sub-tasks: removing very expensive items; checking whether any items in the remaining list are usually used in conjunction with other, complementary, items that are not present and adding these, if they are cheap. The pack_groceries task has three sub-tasks: initializa- tion; packing heavy items; packing light items. In the program text, indentation of FCIPs is used to reflect the nesting of tasks.

Lexical imprecision occurs in the remove_very_expensive_items and add_ cheap_complementary_items tasks. In the working memory, the actual grocery prices are given, but in the FCIP reference is made to cheap and very expensive grocery prices. Fuzzy matching between these crisp actual prices and fuzzy condition patterns is done using an 1-type table for the word expensive and a antonymic relationship between cheap and expensive. Lexical imprecision also occurs in the pack_heavy_items task where there is fuzzy matching between the word heavy, defined in an 1-type table, and the actual weights of grocery containers.


/ * OPERATOR DEFINITIONS, FOR SYNTACTIC SUGARING * / operator(lO,xf, add). operator(lO,xf, take).

::~ operator(lO,xf, put). operator(9,xf, to_selection). operator(9,xf, out_of_selection). operator(9,xf, into_bag).

/ * LEXICAL DEFINITIONS * / table(expensive,food,[0,200], [[20,0], [50,0.5], [70,0.8], [100,1]]) antonym(cheap ,expensive). table(heavy,container, [0,400], [[60,0], [150,0.5], [210,0.8], [300,1]]).

/ * INITIAL WORKING MEMORY CONTENTS * / price(potato_chips ,food ,30). price(butter ,food ,40). price(bread ,food ,30). price(caviar ,food,70). price(jam,food,31). price(pepsi ,food ,35).

weight(potato_chips,container,30). weight(butter ,container, 120). weight(bread ,container ,90). weight(caviar ,container ,90). weight (j am, container, 200). weight(pepsi,container,350).

/ * FORWARD-CHAINING IMPERATIVE PRODUCTIONS * / when untrue doing(_) then store doing(get_initial_selection).

when doing(get_initial_selection) and untrue selected(_) then ask_for_initial_selection.

when doing(get_initial_selection) then replace doing(get_initial_selection) by doing(amend_selection).

when doing(amend_selection) and selected(_) then store doing(remove_very_expensive_items).

when doing(remove_very_expensive_items) and selected(List) and Item in List and price(Item,food,very expensive)

then take Item out_of_selection.


when doing(remove_very_expensive_items) then replace doing(remove_very_expensive_items) by

doing(add_cheap_complementary_items).

when doing(add_cheap_complementary_items) and selected(List) and bread in List and untrue(butter in List) and price(butter ,food ,cheap)


when doing(add_cheap_complementary_items) and selected(List) and potato_chips in List and untrue(pepsi in List) and price(pepsi,food,cheap)

then add pepsi to_selection.

when doing(add_cheap_complementory_items) and selected (List) and bread in List and untrue(jam in List) and price(jam,food,cheap)

then add jam to_selection.

when doing(add_cheap_complementary_items) then remove doing(add_cheap_complementary_items).

when doing(amend_selection) then replace doing(amend_selection) by doing(pack_groceries).

when doing(pack_groceries) and selected(List) then store doing(initialize).

when doing(initialize) and selected(List) then replace selected(List) by unbagged(List) and

provided (List () []) do store bag(bagl,contains([])).

when doing(initialize) then replace doing(initialize) by doing(pack_heavy_items).

when doing(pack_heavy_items) and unbagged(List) and Item in List and weight(Item,container,heavy) and has_room(Bagname)

then put Item into_bag Bagname.

when doing(pack_heavy_items) and unbagged(List)and List () [] and untrue has_room(_)

then start_new_bag.

when doing(pack_heavy_items) then replace doing(pack_heavy_items) by doing(pack_light_items).

when doing(pack_light_items) and unbagged(List) and Item in List and has_room(Bagname)

then put Item into_bag Bagname.


when doing(pack_light_items) and unbagged(List) and List () [] and untrue has_room(_)

then start_new_bag.

when doing(pack_light_items) and unbagged([]) then remove unbagged([]).

when doing(pack_light_items) then remove doing(pack_light_items).

when doing(pack_groceries) then replace doing(pack_groceries) by doing(print_results).

when doing(print_results) and bag(_,_) then print_out_the_bags.

when doing(print_results) then remove doing(print_results) and halt.

/ * DECLARATIVE PRODUCTIONS * / / * a bag has room for more items if it contains less than 3 items* / has_room(BagName) if

bag(BagName,contains(Contents)) and length of Contents < 3.

/ * a bag is the newest bag if there is no other bag whose name alphabetically follows it * / newest_bag(BagName) if

bag(BagName,contains(Contents)) and untrue(bag(BagName2,_) and BagName2 after BagName).

/ * P R O C E D U R E DEFINITIONS * / top ask_for_initial_selection do (output "INITIAL SELECTION:

(one item at a time; to end type "complete")" and newline and store selected ([]) and repeatedly do

(output "Item please:" and input Item and provided (Item () complete)

do (retrieve selected(List) and make Newlist = Item plus List and replace selected(List) by selected(Newlist)))

until (Item = complete)).

to take Item out_of_selection do (remove a selected(List) and

make Newlist = List minus Item and store selected(Newlist)).

Fuzzy multi-paradigm language

to add Item to_selection do (remove selected(List) and

make Newlist = Item plus List and store selected(Newlist)).

to put Item into_bag Bagname do (remove bag(Bagname,contains(Contents)) and

remove unbagged(List) and make Newlist = List minus Item and store unbagged(Newlist) and make Newcontents = Item plus Contents and store bag(Bagname,contains(Newcontents)) ).

to start_new_bag do (provided newest_bag(BagName)

do (make NewBagName = successor of BagName and store bag(NewBagName,contains([])) ) ).

to print_out_the_bags do (newline and

output "FINAL CONFIGURATION: (top item in a bag listed first)" and

newline and for aH bag(Bagname,contains(Contents))

do(output Bagname & "contains" and for an Item in Contents do (output .. . . & Item) anti newline and remove bag(Bagname,contains(Contents))) ).

289

References

[1] T.R. Addis, Designing Knowledge-Based Systems (Prentice-Hall, Englewood Cliffs, N J, 1985). [2] L. Allen, YAPS: yet another production system, Technical Report, Department of Computer

Science, University of Maryland (1982). [3] E. Allen, YAPS: a production system meets objects, in: Proceedings, Conference of the

American Association for Artificial Intelligence (1983) 1-7. [4] J.F. Baldwin and S.Q. Zhou, An introduction to F .R.I .L. - A Fuzzy Relational Inference

Language, Technical Report, Department of Engineering Mathematics, University of Bristol (1983).

[5] J.F. Baldwin, A knowledge engineering Fuzzy Relational Inference Language-F.R.I.L., Technical Report, Department of Engineering Mathematics, University of Bristol (1983).

[6] J.F. Baldwin and S.Q. Zhou, A fuzzy relational inference language, Fuzzy Sets and Systems 14 (1984) 155-174,

[7] J.A. Bowen, MUFL: A Multi-Formalism language for knowledge engineering applications, Technical Report, Department of Computer Science, North Carolina State University (1986).

[8] J.A. Bowen, Programming partly structured problems, Technical Report, Department of Computer Science, North Carolina State University (1986).

[9] J.A. Bowen, Knowledge representation for partly-structured problems, in: Z.W. Ras, Ed., Methodologies for Intelligent Systems (Elsevier, New York, 1987).


[10] J.A. Bowen, Supporting conceptual abstraction in forward-chaining imperative production languages, Technical Report, Department of Computer Science, North Carolina State University (1987).

[11] J.A. Bowen, S. Bull and T. Cornick, BERT: An expert system for brickwork cladding design, in: M.A. Bramer, Ed., Research and Development in Expert Systems IlI (Cambridge University Press, Cambridge, MA, 1987) 207-215.

[12] L. Brownston, R. Farreil, E. Kant and N. Martin, Programming Expert Systems in OPS5 (Addison-Wesley, Reading, MA, 1985).

[13] J.J. Buckley, W. Siler and D. Tucker, A fuzzy expert system, Fuzzy Sets and Systems 20 (1986) 1-16.

[14] W.F. CIocksin and C.S. Mellish, Programming in Prolog (Springer-Verlag, Berlin, 1981). [15] T, Cornick and J. Bowen, A knowledge based expert system for brickwork cladding design and

production, in: Proceedings, CIB.86, Vol. 2, Knowledge-Bused Expert Systems to Aid Decision Making (1986).

[16] R. Davis and J. King, An overview of production systems, Machine Intelligence 8 (1977) 300-332.

[17] F. Eshragh and E.H. Mamdani, A general approach to linguistic approximation, Internat. J. Man-Machine Stud. 11 (1979) 501-519.

[18] C.L. Forgy, OPS5 user's manual, Technical Report, Department of Computer Science, Carnegie-Mellon University (1981).

[19] C.L. Forgy, OPS83 report, Technical Report, Department of Computer Science, Carnegie- Mellon University (1983).

[20] J.M. Francioni and A. Kandel, A software engineering tool for expert system design, IEEE Expert 3 (1) (1988) 33-41.

[21] J.H. Griesmer, S.H. Hong, M. Karnaugh, J.L. Kastner, M.I. Schor, R.L. Ennis, D. A. Klein, K.R. Milliken, H.M. Van Woerkom, YES/MVS: a continuous real time expert system, in: Proceedings, Conference of the American Association for Artificial Intelligence (1984).

[22] R.D. Hayes-Roth, D. Waterman and D. Lenat, Building Expert Systems (Addison-Wesley, Reading, MA, 1983).

[23] Inference Corporation, ART Reference Manual (Inference Corporation, Los Angeles, CA, 1986).

[24] Intelligenetics, KEE, A Knowledge Engineering Environment (Intelligenetics, Inc., Palo Alto, CA, 1983).

[25] P. Jackson, Introduction to Expert Systems (Addison-Wesley, Wokingham, U.K., 1986). [26] P.L.K. Jones, A model of organisation dynamics, in: M. Small, Ed., Policy Evaluation using

REVEAL (ICL, Manchester, UK, 1985). [27] H.F. Korth, (1986), Extending the scope of relational languages, IEEE Software 3 (1) (1986)

19-28. [28] J. Lebailly, R. Martin-Clouaire and A. Prade, Use of fuzzy logic in a rule-based system in

petroleum geology, in: E. Sanchez and L.A. Zadeh, Eds., Approximate Reasoning in Intelligent Systems, Decision and Control (Pergamon Press, New York, 1987) 125-144.

[29] R. Lefaivre, FUZZY: A programming language for fuzzy problem-solving, Technical Report, Department of Computer Science, University of Wisconsin, Madison (1974).

[30] F. Lynch, C. Marshall, D. O'Connor and M. Kiskiel, AI in manufacturing at Digital, AI Magazine 7 (5) (1986) 53-57.

[31] E.H. Mamdani and S. Assilian, An experiment in linguistic synthesis with a fuzzy logic controller, Internat. J. Man-Machine Stud. 7 (1978) 1-13.

[32] T.P. Martin, J.F. Baldwin and B.W. Pilsworth, The implementation of FPROLOG- A fuzzy Prolog interpreter, Fuzzy Sets and Systems 23 (1987) 119-129.

[33] R. Martin-Clouaire and H. Prade, SPII-I: A simple inference engine for accommodating both imprecision and uncertainty, in: G. Mitra, Ed., Computer Aided Decision Making (Elsevier, New York, 1986).

[34] C. Mellish and S. Hardy, Integrating Prolog in the POPLOG environment, in: J.A. Campbell, E.d. Implementations of Prolog (Ellis Horwood, Chichester, England, 1984).

[35] J. McDermott and C. Forgy, Production system conflict resolution strategies, in: D.A.


Waterman and F. Hayes-Roth, Eds., Pattern-Directed Inference Systems (Academic Press, New York, 1978).

[36] J. McDermott, RI: A rule-based configurer of computer systems, Technical Report, Department of Computer Science, Carnegie-Mellon University (1980).

[37] J. McDermott, Extracting knowledge from expert systems, in: Proceedings of the Joint International Conference on Artificial Intelligence (1983) 100-107.

[38] J. McDermott, Building expert systems, Technical Report, Department of Computer Science, Carnegie-Mellon University, (1983).

[35] K.R. MiUiken, A.V. Cruise, R.L. Ennis, J.L. Hellerstein, M.J. MasuUo, M. Rosenbioom and H.M. Van Woerkom, YES/LI: A language for implementing real-time expert systems, Research Report RC 1150 (#51654), IBM Thomas J. Watson Research Center, Yorktown Heights (1985).

[40] A. Newell (1973), Production systems: models of control structures, in: W. Chase, Ed., Visual Information Processing (Academic Press, New York, 1973) 463-526.

[41] J. Ostergaard, Fuzzy logic control of a heat-exchanger process, in: M. Gupta, G. Saridis and B. Gaines, Eds., Fuzzy Automata and Decision Processes (North-Holland, Amsterdam, 1977).

[42] R. Paige, Programming with invariants, 1EEE Software 3 (1) (1986) 56-69. [43] S. Polit, R1 and beyond: AI technology transfer at DEC, AI Magazine (Winter 1985) 76-78. [44] M.I. Schor, T.P. Daly, H.S. Lee and B.R. Tibbitts, Advances in RETE pattern matching, in:

Proceedings, Conference of the American Association for Artificial Intelligence (1986) 226-232. [45] B. Sheil, Power tools for programmers, Datamation (Feb. 1983) 131-144. [46] W. Siler, J. Buckley and D. Tucker, Functional requirements for a fuzzy expert system shell, in:

E. Sanchez and L.A. Zadeh, Eds., Approximate Reasoning in Intelligent Systems, Decision and Control (Pergamon Press, New York, 1987) 21-32.

[47] W. Siler, D. Tucker and J. Buckley, A parallel rule firing fuzzy production system with resolution of memory conflicts by weak fuzzy monotonicity, applied to the classification of multiple objects characterized by multiple uncertain features, lnternat. J. Man-Machine Stud. 26 (1987) 321-332.

[48] W. Siler, FLOPS: A fuzzy expert system shell, in: Proceedings, 2nd Conference of the International Fuzzy Systems Association (1987) 848-850.

[49] A. Sloman, POPLOG: a multi-purpose multi-language program development environment (Cognitive Studies Programme, University of Sussex, Brighton, England, 1983).

[50] M.J. Stefik, D.G. Bobrow and K.M. Kahn, Integrating access-oriented programming into a multiparadigm language, IEEE Software 3 (1) (1986) 10-18.

[51] B. Stroustrup, The C+ + Programming Language (Addison-Wesley, Reading, MA, 1986). [52] P.A. Subrahmanyam and J.-H. You, FUNLOG: A computational model integrating logic

programming and functional programming, in: D. De Groot and G. Lindstrom, Eds., Logic Programming: Functions, Relations and Equations (Prentice-Hall, Englewood Cliffs, N J, 1986).

[53] M. Togai and H. Watanabe, Expert system on a chip: An engine for real-time approximate reasoning, IEEE Expert (Fall 1986), 55-62.

[54] M. Togai and P. Wang, Analysis of a fuzzy dynamic system and synthesis of its controller, lnternat. J. Man-Machine Stud. 22 (1985) 355-363.

[55] M. Tokoro and Y. Ishikawa, Orient84/K: A language with multiple paradigms in the object framework, Proceedings, Hawaii International Conference on System Sciences (1986).

[56] T. Whalen and B. Schott, Issues in fuzzy production systems, lnternat. J. of Man-Machine Stud. 19 (1983) 57-71.

[57] P.W. Winston, Artificial Intelligence (Addison-Wesley, Reading, MA, 1984). [58] L.A. Zadeh, A theory of approximate reasoning, Machine Intelligence 9 (1979) 149-194.

FMUFL: A fuzzy multi-paradigm language

Documents

Transcript of FMUFL: A fuzzy multi-paradigm language