Integrating Declarative Knowledge Programming Styles and Tools in a Structured Object AI Environment

INTEGRATING UECLARATIVE KNOULFDGE PkOGRAHHING STVLFS AND TOOLS IN A STRUCTURED OBJECT AI ENVIRONMENT

Hihai Barbuceanu Stefan Trausan-Hatu

Institute for Computers and Informatics 8-10 Hiciurin, 71316 Bucharest I phone 653390 6 telex 11891 icpci r R KANIA

ABSTRACT

XRL is an integrated knowledg~ programming en vi r-onmcn t whose major resea..-c h theme is ttl(~ investigation of declarative knowledge prograMming ~txles and tools, and of the way they can bC effectively inte9rated and used to support AI programming. Thts investigation is carried out in the context of the structured-object represen tal ion paradigm which provides the glue keeping XRL components together. The paper describes several declaral1ve programming styles and associated support tools currently available in XRL .

I. I NTROIJUCT I ON

Recent research [I] prompts the view that the success of AI knowledge based programs is a direct consequence of a specific approach to progra~ing in which the programmer construe t s declarative specifications directly interpretable by the supporting programming system, rather than of a different nature of AI programs.

If one shares this view las we do), then developing better declarative progra~ing languages and language features providing leverage for this approach to programming becomes an essential research direction.

The XRL system reported in this paper is one such attempt. It is an integrated knowledge programming environment whose major research theme IS the investigation of declarative knowledge programming styles and features and of the way they can be effectively integrated and used to support AI programming.

The paper presents the most important declarative programming styles and associated tools currently available in XRL. These tools are organized in the layered architecture shown in fig. 1.

The structured object layer for·s the substrate of the whole environment providing \he glue which keeps everything together. The Instantiation framework supports a generalized view of the ubiquitous frame instantiation process . The description based programming syste~ provides a novel dec larative programming style which embedds a mathematical orienteo description language in the structured object environment. The semantics oriented programming framework offers a specific semant1c construct ba~ed approach to programming which supports ~aintainance and evolution. Finally, the self 9eneration tool applies this approach to XRL tlself.

. self generation framework support for semantics-oriented programming description based programming instantiation framework forward rule system structured obJect representation L I S P

fig. I : XRL arc hi tee ture Balint Holnar Central Research Institute for Physics H-1~25 Budapest 114, P.O.B. 49 HUNGARY

II. STRUCTURED OBJECT SUBSTRATE

A. Structured object~

This layer provides an object-centered programming systl?m [2-6] . Stn1c lured ObJects come an two forms: generic object~, called un1 ts which stand for cldsses of object s and individual ob~ects <instances). Units are composed of slot'.. which have values and m~ta-descriptions. Meta-descriptions, which also apply for .units as a whole, are specified in terms of o ther first c·rder units which can be meta-described themselves by means of other meta-units a.s.o ..

A unit exampl~ is shown in fig.? . Its meta-description appears in the self slo.t. The notation Ia <unit name ) .. . l defines a "virtual copy· of <unit name>. It is an anonymuus unit which can he used in a single place . It inherits all the slots defined by <unit name>. The slots Mentioned in the notation are added to the new unit, overriding the corresponding ones from <unit name>. At this level meta-descriptions are used to store specifications of inheritance relations Cthe supers slot) and the association of methods to selectors !the draw and refine-by slots> . A full language for specifying method combination is also provided in [71 .

[House

self <a HouseHetaUnit supers <Rui ldin~ Property) subtask-processtng-order sequence pre-cond Cask ·uorking on House?") post-cond !TrueSlol is-affordable?> not-affordable (an Event draw DrawHouse I slot is-affordable? pr-edicate not handler HouseNotAfdb) room· I y pe ~ < set of ( set Hed room Living IIi n i ng Bathroom Kitchen> · such-that UserApprove<,) (a SODLHetaUnit refine-by Filter) rooms Csetof :0: <a :1: rooml) Ia SODLHetaUnit labels 1:1: :0:1 :1: Ia SpecializationHultiSetC:onstr speciali~ation~ (any room-types) multiplicity AskUserl . :0: Ca UholeSetll is-affordable? <using!income<path owner income>> <HouseAfdb? income cost maintainance-costl) maintainance-cost CComputeHC rooms) cost Ia Cost I !an ADTValuedSlotll

Fig. ?: The House unit

This layer als~ supports an abstract data type CADTI programming faci I tty. ADT-s arc de..,cribed as usual units <slot cost in fig.2l, but are interpreted by a special compiler- for variable creation and manipulation (somewhat similar ADT-s are provided in [5ll.

As efficiency at this level is vital for the whole environment, time consuming processes such as Method combination, message sendino and AliT creation and manipulation are carefully"compiled.

Ill. THE INSTANTIATION FRAHEUORK

A powerful and widely used mechanism for bringing the knowledge encoded in structured-object representations to bear is instantiation, a process by which the knowledge contained in a generic object is applied to tne construction of a similarly structured terminal object. In spite of the ubiquity of instantion in frame or object-centered systems, few languages explicitly support this process. One of these rare cases is LOOPS [3] with its composite objects, but even here only 1 rigid recursive mechanism is provided. XRL fills tnis gap with a generalized instantiation engine discussed below.

A. Instantiation tasks

Central to the instantiation framework is the concept of task. The task is the processing unit of the instantiation system. Tasks may represent generic objects in course of instantiation, AOT-s to be created or operated upon or arbitrary LISP expressions to be evaluated. Each of this is allocated an instantiation region on the blackboard. Considering the House unit (fig.2l, the system will associate a task to the unit as a whole and several subtasks to each of its slots. Among the latter we note an AOT to be created <the cost slot> and a LISP expression to be evaluated <the maintainance-cost slotl. The tasks generated for room-types and rooms belong to the description-based programming layer to be discussed later on. As 1llustrated by the example, there exists a task-subtask hierarchy stemming from the structured nature of units and inducing a tree-structured organization of agendas.

B. Specifying task processing

Task processing is accomplished according to an instantiation protocol. This protocol is defined as a convention about the meaning of a number of selectors involved in message passing activities triggered by the various components of the instantiation system.

The instantiation protocol specifies the following issues: (I) 'The cond i lions under whi('h a slot is to be processed as a subtask. (2) The pre-conditions enabling a task to be selected for execution. (31 The post-conditions for successful task processing. (4) Colateral actions to be performed before or after task processing. <51 Task priority; a given task may decide on its own priority as well as on the priorities of its subtasks or of other tasks whose results are needed for its own processin9. (61 Actions to be carried out for execut1ng a task. <71 Descriptions of exceptional events and of the associated event handling activities.

Some of this possibilities are illustrated in fig . 2, the self slot.

C. Communication and synchronization

In order to allow tasks to communicate to each other and to provide mechanisms for programming task placement in the agenda, the system introduces two new primitives. The path primitive <see slot is-affordable? from fig. ?l specifies dynamic access paths to the instantiation regions of other tasks. Thus, <path owner income> creates an access link to the income slot of the instantiation region associated to the unit filling the owner slot of House unit . Path-s automafically schedule the tasks using them after the value they need becomes available.

The second primitive is the using con?truct (see also slot is-affordable? in fig.21 which binds variables to the objects refc re~ccd by its inner paths . In fig.2 variable income will receive the value of the owner 's income lwhen available>.

To p..-ogram various control policle?, the message pa~sing protocol allows Ill any task to modify its own oriorily, <:?1 a task to modify the prioYi ty of the tasks it references through path-s.

D. System organization Task processing is organized "instantiation systems· <ISI which declaratively descr1bed as units <fig.31. [House Design 1 S self <an ISKetaUnit supers <InstantiationSystemll spaces (specs-acq designl specs-acq <a Space unit House task-sel-fn task-eligible? lnce-on Tl du1gn <a Space unit Housenes ign pre-cond <done-space specs-acql task-activate-fn task-activate> statu < sl l !.I <an ISState spaces <specs-acq design> select-space first-ok interrupt-space no finish-space no-tasks next-state ·final-state·> sys t -pre-cond T to-run-fn ·ISRunl Into are

An IS is composed of an agenda and a number of spaces (blackboard zones I. In each space a network of instantiation ·regions generated by the ~rocessing of an initial tinit can be constructed. Each IS may be individually manipulated by the programmer. This means it can be c..-eated, run, interrupted, resumed, modified. This mechanism offers flexibility in dividing the initial problem into subproblems and in handling the interactions between them. For example, we used it in a number of design applications to mana9e different phases of the process such as specification~ preliminary design, detalied design, evaluation (~J.

The system al~o provides a dependency handling facility. Dependencies are created by explicit paths or by referencing slot names in the methods or expressions used in a unit <see fig.2l.

E. Control regimes

Besides instantiation, other control regimes are avai !able at this !eve I. Dependency dYiven backtracking exploits the dependency records allowing selective network modification by tracing back tne elements from which the offending value was derived.

The replay regime allows reprocessing a network modified by dependency dr1ven backtracking by reinstalling ·seed" tasks in the agenda and reusing previously der1ved results when process1ng these tasks.

The event handling r·egime, cnter·ed whenever an event is generated, offers an encompassing set of event handling options. In fig. ? some of the slots and units involved in declarin9 events and specifying handlers drc exemplif1ed. The not-affordable event is raised by the violation of the task post-·condition and is tr t! ated by the HouscNotAfdb routine.

It is now pos ~ ible to understand how the Hou~e unit will be treated if passed to this problem solver. All its slots <including those inherited) will be considered as subtasks and sequentially processed. The unit will not be processed <1nless th~ u ~er approves it. Because of the existing dependency relations the is-affordable? subtas~ will be scheduled after the owner 's income, cost and mainlainance-cost tasks.

IV. DESCRIPTION BASED PROGRAHHING

The PBP lay€r is an attempt to formalize a notion of higher lo!vel <Hll structu..-ed object and to create a programming system based on it.

Programs written in terms of HL structured object~ and their ~pecific inference models can be factored into a der,cription of the specification (what should the prog r am compute) and a description of the implementation (how should the computation proceed). The~e lwo description~ are separate{ thus allowing separate understanding and manipula ion of ~pecific~tions and implementations.

Ue view three major advantages of this strle of programming . First, the higher level character which allows programs to be specified in abstract, mathematical terms for which a clearly understood ,emanti cs exists . Second, the separation of specification from implementation which makes it possible to under~tand the specification of a program without having first to simulate in mind its implementation, which is what necessarily happens with procedural representations and imperative programming in general. Third, the introduction of a more mathematical view on structured objects which h~s a positive influence on the understanding and utilization of this representation paradigm.

A. The set oriented description language <SOOL)

Uhile the meaning of "framas· or structured obJects varies heavily across the range of extsting languages, SODL builds upon the interpretation of an XRL generic object as a class of terminal objects (instances). This is consistent with the stand taken by the underlying instantiation layer which constructs instances of generic objects. SODL provides a set oriented language for describing the classes of objects which can fill the slots in instances of generic ObJects.

First, here is the syntax of SODL. Description-> Unit <oneof Set (suchthat PJ) <setof Set Csuchthat PJ) Set

Set -> Elm -> Unit (setof Set (suchthat PJ) (or Set . . . ) ; set union (and Set ... ) ; set intersection <diff Set ... ) ; set difference <set Elm ... ) ; explicit enumeration Lisp-object ! Instance

SODL descriptions can be divided into two categories. Element descriptions (oneof Elm) describe an entity as belonging to a set of objects. Set descriptions describe sets (1) as sets of instances of a given unit, (2) as subsets of another set <setof ), and (3) by usual set operations. In the current version, predicates are lambda expressions of one variable.

In fig.2, two very simple descriptions are used. In the room-types slot, a setof description describes the possible room types in the house. The setof description in the rooms slot specifies that it c~n be filled with a set of instances of the Room unit. As a more complex example,

(oneof<setof(a NiceGirl studies CS) suchthat (height < 180) > suchthat <eyes-colour= blue))

describes a girl with blue eyes from a set of NiceGirl-s studying AI and having height < 180.

B. Semantics of SODL

A SODL description which fills a slot in a generic unit describes the class of individual objects or sets of objects which can possibly fill that slot in any instance of the unit. A SODL description thus stands for a class of individuals or a class of sets of individuals.

To clarify the meaning of SODL, we briefly define <in a manner akin to (9]) a formal semntics for SODL based on the notion of description extension. The extension of a description d is the set of elements described by d. A function E from descriptions to either elements or sets from any domain n is an ·~tension function if ~nd only if it satisfies the following properties:

1. EC Un i tl=Powerse t< Instance-of <Unit)) 2.EC<oneof S Pll=!x/x€l&I~E<S)&P(x)J 3.Er<setof S P)J=Powerset!x/xEI&l6E(S)&P!x)J 4.EC<or S1 ... Sn)J=!I/I=Uii&IieE<Si)J ~.E[(and Sl ... Sn)J~!I/I~nii&liEE(Si)J 6.EC<diff SO S1 ... Sn)J=!I/V~~IO&IOEE<SO)-> ->xti i&I iEF < Si)} 7.EC<set E1 .. . En)J=!!E1 ... EnJJ 8.~[Lisp-object!lnstancel~£Lisp-object!InstanceJ.

Looking at how a subset of description's extension u completed, it is important to ana.lize the first three rules above. All of them describe a kind of choice from alternatives. The oneof rule describes the choice of an element. The setof rule describes the choice of a subset of a set while the unit rule describes the choice of a subset of instances of a given unit.

C. Reasoning with descriptions

An important notion at least two useful reasoning models can be based on is that of refining a description. If dl and d2 are descriptions, then d1 is a refinement of d2 iff E<dl )C E<d2) for any E and D. Thus stated, refinement is the same thing as the subsumed by relation defined in [101. The description language and the way in which refinement is used in reasoning differ however fundamentally from languages like KLONE C!Ol , OMEGA [121 or KRYPTON [ 11 J. Namely, we adopt a generative reasoning model in which the problem solver starts with an initial description and incrementally produces more and more refined descriptions from it, until a satisfactory level of refinement is attained !including of course the determination of terminal elements). For example, in fig.4 an initial description and two stages in 1ts incremental refinement process are illustrated.

CAIGirls elements <setof <a UiseGirl) )J

CAIGirls-05

elements <setof<or(a Girl age 39)

(A!Girls-17

In! tlal unit

; stage

<a Girl boyfriend <an AIGuy)) <a Girl IQ 200) )J

elements (set lucy Ann Jane Lola)]

; stage 2

Fig . 4: An example of incremental refinement

A second possible reasoning model is a recognition-based one in which a given unit is compared to other units in a knowledge base. The comparison may reveal <most specific) subsumers in which case the unit is classified in the knowledge base (in the style of the above cited languages (10-121) or (most general) refinements in whtch case the unit may act as a template for associative retrieval. The recognition based mode can and should be integrated with the generative one. For example, the object Jane <fig. 4) might had been retrieved as a refinement of Ta Girl IQ 200). Currently, the existing DBP srstem supports the generative refinement model and only rudimentary recognition mechanisms. Host important, DBP lacks for the moment a program able to decide if, given two SODL units, one is a refinement of another. Ue view integrating generative and classificatory reasoning as an Important topic for the near future .

D. Operationalizing the incremental refinement model

I> The nature of operationalization. Consider the description:

(oneof :0: <setof :1: <a :2: Student studies AU suchthat (height> 180)) suchthat <age < 30))

One possible operationalization is as follows. At :2: search the KB for instances for the given unit for at most 10 units of time. At :1: f1lter the resulting list with the given predicate and retain the first 5 instances. At :0: take the first instance satisfying the predicate.

Several aspects are worth noticing. First, an ~lement from the extension is computed. Second, it is determined by search . Third, with the impo,ed resource limitations it may well happen that no suitable elements be found.

A lot of other operationali~ations can be obtained by altering the above one : <a> replace search with instance construction (done with the instantiation processor); Cb) instead of two filtering steps perform only pne and-ing the two predicates <done through a syntactic transformation>; <c) replace unit Student with tht' union of its specializations. Provided these ~pecializations have more efficient methods for constructing or retrieving instances, this semantic transformation may improve lhe efficiency of step :2:.

21 The operationalizatlon framework. The framework recognizes four dimensions along which operationali7atlon can be performed: search, construction, syntactic and semantic description transformation. Ue have adopted a rule-based form for encoding the operationalization procedure which fall into the above categories. For this purpose we use the . XRL production rule system. This a forward reasoning system which allows defining both rules and rule interpreters in a uniform and extensible object oriented notation <similar approaches are (4,1511.

CUnitToUnion

self <a SemanticTrHetal variables <Specs Unit) descr-conditions del proc-conditions (pel pc21 del <IsUnit Unitl pel <Exists Specs <SpecOf Unitll pc2 <not<HaveMethods Unit '(toconstruct tofindl)) recommend <HaveMethods Specs '(toconstruct-inst tofind-inst>>

new-description <MakeUnion Specs)]

If: <1> the description is a unit

<2> there exist specializations of it

<3> the units does not have to construct or to find instance methods

Then: transform it into a union of its specializations

Recommended: if the specializations have methods either to construct or to find instances.

Fig. 5 UnitToUnion semantic transformation

Fig.5 illustrates a semantic transformation rule wnich transforms a unit into the union of its specializations. Recommendations identify situations where the rule is likely to be especially effective.

The framework defines several standard operationalization regimes. One is interactive, user-guided operationalizalion in which user selects the rules and system applies them. Another is a default automatic one which attempts to operationalize any DB program even if no operationalization information is provided <done using defaults>. Finally, the third executes a single rule for each description, covering the case when the programmer can precisely define the operationalization activities.

The processing of the descriptions used in fig.2 can now be understood. The room-types slot selects the types of rooms by filtering a given set of alternatives with a predicate which triggers user questioning. The rooMs slot spec1fies that a set of specializations of unit Room must be constructed in the following manner. The specializations are those units w~ose names appear in the room-types slot and the number of occurences for each ~pecialization <i.e. room trpe) is interactively given by the user <label : : l and the whole set thus produced wi II be retained as the slots values <label :0: I.

E. Applying DBP

Ve view the usefulness of DHP for applications which can be modelled by an incremental refinement process whirh starts .with high level but operat1on~l sp~c1flcat1ons and incrementally transforms them 1nto lower level descrjptions.

Hany design problems can be modelled in this way. (141~ ranging from mechanical design (15] and CIVIl eng1neer1n~ des1gn (16) to program synthesis [17J. Our use of DHP has been in this direc tion and is reported in [8,!9] .

If we consider the di~tinction between classification and constructive problem solving made in (181, DBP appeares ilS a tool for the latter. . It is a mechanism for creating and assembling local solut1ons and objects 1nto higher order aggregates which are not part or a pre-existing ennumcration. This may suggest OHP <w!th the languages below> as a generic tool for thls type of problem-solving. To attain this objective, what we currently have can only be a f1rst step. Huch work is still required especially more app lie a lions. '

V. SEMANTICS-ORIKNTKO PROGkAHMING AND SELF-GENERATION

The programming tool presented in this section supports a semantics-oriented programming methodology whose major advantage is a knowledge-based mechanism supporting program modification. Other advanta9es are better understandability and reusability of the programs thus developed.

A. Semantics-oriented programming constructs

Th~ central conc~pt of our approach is the semantic construct not1on. The nature of semantic constructs can be best understood by means of an analogy between programming language constructs and the constituents of grammars used in natural language understanding.

The constructs of general-purpose programMing languages are domain-indepenent structures<e.g. 1f .statements or ~eal data types I in terms of which programs 1n any problem domain can be constructed. They are analogous to the constituents of general NL grammars <such as noun phrase or ~erb phrase>. Semantic con~tructs play a role s1m1lar to the constituents of semantic grammars (201. They are related to the semantics of the problem do~ain and provide a strong conne~t1on between th1s doma1n and the language the domain is encoded in.

An example may help elucidate this. Assume the domain of discourse is the instantiation framework of XRL and we have several routines whose processing depends on the state of the ~urrent task. In a general-purpose language like LISP we could encode lhese routines according to the following pattern:

<defun <name> <task> !prog<s> (cond((eq(setq s<cadddr task)) 'new> <processing the new state>> ( < eq s ' ac ll ve I <processing the active state>> it ferro~ ·t~sk state inexistent~>>>i>

For this particular domain, we can also define a special . semantic construct called, e.g. TaskP~ocess1ngProc<edurel. In a structured object notat1on the concept could be defined as shown in fig.6. Also in fig.6 we illustrate the general paltern for using it.

[TaskProcessingProc

self <a SemanticProcedureHetaUnit supers <DataParameteri~edProcll arguments <task) args-types <taskl test task:state possible-values <new active .·. done) error-signalig <error "task state inexistent'!] <a TaskProcessingProc new <processing for the new state> active <processing for the active state> done <pr~ces~ing ·for . the ·don~ st~te>i

Fig . 6: TaskProcessingProc definition and use

. Comparing the unit for using the construct with the LISP code shown earlier we note the following clear advantages :

lll The notation is easier to perceive and understand as things like the prog and cond structures,the tests in each cond clause, the way of access1ng the task state and the local variable do not appear . Their function is automatically provided by the semantic construct.

(21 Knowledge about the problem domain, such as the possible task states, is embedded in the definition of TaskProcessingProc and automatically applied when the construct is utilized.

<31 Programming disciplines, such as the manner of error signaling, can be clearly

enforced. <41 Programming knowledge, e .g. the manner of accessing the state of a task, is also embedded In the concept definition and automatically applied.

In fewer words, the semantic construct is more ~:~ndersta':ldable as . it clearly relates the 1nformat1on 1t conta1ns to the problem domain and is knowledge intensive as it embedds a variety of knowledge about the problem domain and the programming process.

Kore than that, the structured-object representation is easier to modify. Several kinds of semantic manipulations which are useful for maintainance can be trivially accomplished in this representation in a fully automatic manner :

< 1l ldenti fying existing task states !?I Identifying to a given task state <31 Identifying signaling part f4J Identifying access mechanism. and modifying the the processing associated and modifying the error and modifying the state

On the initial LISP representation neither of these manipulations is easy to automate . The major reason is that in the semantic construct the relevant information is semantically tagged and thus easily accessible and interpretable. In the usual <LISPI representation only complex analysis of the code would eventually reveal the semantic role of the syntactic constructs used <e.g. the s ~ar i able, the cond or the prog I. Another reason IS that the semant1c construcl has a locality property (211. Information spreading optimizations typical at the code level <such as the caching of the task statel have no place at this level.

B. Structured object constructs support for semantic

Threa kinds of services are provided for programming with semantic constructs. 11 Organization into inheritance lattices. This allows semantic concepts to be efficiently composed by combining various features available from other constructs in the lattice.

21 Compilation. Semantic constructs can be efficiently compiled into executable code by attaching code generation methods activated by the instantiation processor. Code initially scattered on leaf instances of the instance tree i~ latter assembled in parent instances until the final code

ts pYoduced.

31 Semantic editina. This is the process by which the behaviour ol a program is changed according to a g1ven purpose. As semanl1c constructs explicttly Yepresent semantic infoYmation, semant1c editors can efficiently Yetrieve and interpret th is informa t ion to achieve their goals.

Consider the T3skEligible ? routine f ~om fig. / which determines task eligibility for execution by the instantiation proces soY. Suppose one needs to produce a new veYsion which would not consider not -yet as a possible answer to star·t -i f and resume-if messages. !These may be needed for cu stomi zing the system to a spec ifi c application). FiYst, this Y'lquest can be reformulated as "remove the not-yet entry from the msg-pos -answ s lot". To cany it out, a generic semantic editor for this type of semantic editing would have to perform !by itself) the following s1mple actions: Ill r·emove the specified entry from the msg-pos-answ slot; 121 retrieve, for each task state, the places where the removed value is used. As the u~e of message passing is restricted to J few semantic const ructs !such as HessagePassingCa sel defined i n advance, this is quite easy to do; (31 edit the above found co nstructs. For M<JssagePa ss ingCase-s (and similar ones) thi s aments to removing the not-yet slot and eventually creating some new units, which take primitive operations in th8 language. Domain specific demons can augment this general editor by checking whether the suspended state of the task, whJ ch was se t in this case, does not become suped Juous . If i I dr,es , new editing is triggered this time on the Task abstYact data type.

(TaskF 1 igible?

self Ia SemanticProcedureMetaUnit supers ITaskProcessingPYoc . MessagePas singProtlnterpProcll msg <select-if Yesume-if I msg-pos-an sw ((select-if t drop not-yet faill (resume-if t drop not-yet failll default -msg-answ ((select-if tl(resume-i f til not-in-range-event (select-val-not-in-range) new (a HessageP assingCase selector select-if send-to Task:instance t <se lect task> drop <do not select ) not-yet <make task suspended ) fai 1 <exit instantiation system> I ... J

Fig. 7: TaskEiigible? unit

C. Discussi on

Uhen designing semantic constructs, the progYammeY must have already acquired a good understanding of the application domain . Semanti c editors appear as local mutation mechanisms able to turn an existing construct into a class of different useful and meaningful constructs . Uhat consti lutes a meaningful mutation must be decided in advance for each constYuct. Meanin9ful mutations can be seen as modifying some prev1ous assumption made during program design. This idea may be fruitful for further developments of this approach.

This explains why with semantic constructs the programmer is not designing a single program, but a class of potential progYams any of which can become real by appropriate semantic editing. This helps enforce a kind of design for change.

The Programmmer ' s AppYentice [22] uses plans to captuYe middle level progYamming knowledge. Our semantic constructs are aimed moYe at Yepresenting problem specific know ledge. This makes semantic editing possible and distinct from what is ment in [23] by knowledge-based editing. This distinct ion also explains the use of a special plan language in [221 and the use of a more geneYal repYesentation language for semantic constYucts. The Draco [14J syslem also uses problem oriented languages, but its major goal is to achieve reuasbility and the technology used quite different.

D. The self generation layer

The approach presented in this section has been applied to several of the XRL components. At the inst-'lntiation level 1 the whole instantiation processor has been generated in this manner·. The rule system employed by DBP was al so construc ted in thi~ way.

ExIsting modify the instantiation interpreters rules and for semantic editor s can be used to instantiation protocol , the system mechanism, fo r building for new types of operationalization modifying the exi s ting ones.

The semantic editing idea has been further extended by associating an appli cati on analy ~ is program which scans an XRL application knowledge base to see whether a simpler and more efficient XRL interpreter can handle it. Thi s may happen e.g. when only a few of the capabilities provided by the instantiation protocol are actually used . If this is possible <dec ided by heuri s ti c rules invocked over collected data>, semantic editing is automatically applied t o actuall y create the simplified XRL interpreter.

VI. F I MAL Rf.HAII.KS

Uhi le there exist several environments which exploit a structured object substrate for developing more declarative implementati ons of programming tools [2-6), XRL is different in the nature of its components. These compone nts attempt to support higher level knowledge programming issues such as instantiati on, descriptive programming and semantics-oriented support for proceaural programming.

XRL has been used in several expert systems , mainly in the design area. Previous work investigated its appl ica5ility as an environment for design problem-solving (8,19) . The approach to procedural programming has been generalized t o a semantics-oriented software development model supporting evolution and reusability ( 25 J .

Huch work Is still needed for bette r assessing the potential of description based programming, for deve loping mo re <kinds of) operationalization rules and more applications built on it. The integration of constructive and c lassifi catory reasoning is also an important topic for future research.

More measure replaced general seman-tic work is al so needed for evaluating the in which procedural programming can be with OIJr object oriented lool and in for assessing the possibi 1 i ties of using construct s in programming .

These developments are related to a longer range effort of creating a general software and knowledge engineering environment integrating declarative programm1ng styles and tools of the kind discussed here.