From natural language to shell script: A case-based reasoning system for automatic UNIX programming

From natural language to shell script: A case-based reasoning system for automatic UNIX programming

Expert Systems With Applications, Vol. 9, No. 1, pp. 71-79, 1995 Copyright © 1995 Elsevier Science Ltd Printed in the USA. All rights reserved 0957-41...

665KB Sizes 9 Downloads 100 Views

Expert Systems With Applications, Vol. 9, No. 1, pp. 71-79, 1995 Copyright © 1995 Elsevier Science Ltd Printed in the USA. All rights reserved 0957-4174/95 $9.50 + .00

Pergamon

0957-4174(94)00050-6

From Natural Language to Shell Script: A Case-Based Reasoning System for Automatic UNIX Programming WON IL LEE AND GEUNBAE LEE Department of Computer Science and Engineering, Pohang Universityof Scienceand Technology,Pohang, Korea

Abstract--We present a case-based approach for natural language interface to a UNIX system

with automatic programming ability. Natural language commands are analyzed by case-based parsing and then transformed into UNIX shell-scripts by case-based planning with derivational analogy. Our system, a Dialogue Interface to uNIX ( DINX ) demonstrates that natural language parsing should be augmented with automatic programming to provide efficient and user friendly interfaces. We suggest case-based reasoning as a unifying framework to combine natural language parsing with automatic programming in a synergistic way.

1. I N T R O D U C T I O N

command and builds a new memory structure and transforms it into the corresponding shell-script. In section 2 related articles are examined, and in section 3 our methodologies are introduced~ The architecture of DINX is shown in section 4, and in section 5 a sample run of DINX is traced.

NATURAL LANGUAGE is one of the most comfortable ways to communicate between computers and humans. However, developing a natural language commanding system is not a simple task. What makes the situation worse is that a natural language sentence is seldom procedural. Everyday users don't want to deliver entire procedures to the computer to accomplish what they want. They just say " I want to do this" or " d o this" and expect the computer system to realize what they said. This suggests that a natural language interface needs more processing beyond the simple understanding of the utterance. An automatic programming facility to make a computer find the procedures for what users want is the most important one. In this article, we present a methodology of combining natural language parsing and automatic programming in a case-based framework. We developed a natural language interface system to UNIX with automatic programming ability. In our system, a Dialogue Interface to uNIX (DINX), natural language commands are analyzed using casebased parsing and transformed into UNIX shell-scripts through case-based planning. For example, when a user enters a command "list the name and owner of the file whose size is greater than 10K," DINX parses the

2. PREVIOUS RESEARCH ARTICLES Automatic programming systems transform user's requirements stated in logic-based specification languages or natural languages into a program. Currently, four methods are used for the automatic programming: procedural methods, deductive methods, transformation methods, and inspection methods (Rich & Waters, 1988). Among these, transformation methods and inspection methods are closely related to our approach. In DINX, case-based planner searches for a case that is similar to the current input and solves the current problem using the best retrieved case. This idea is basically the same as using the clich6 in the inspection method (Rich & Waters, 1990). The content of the case in our system is the history of transformations from the high-level description to the low-level program. UNIX consultant (UC) (Wilensky, Arens, & Chin, 1984) is an intelligent UNIX advisor that allows naive users to communicate with the UNIX operating system in English. It takes an English sentence as its input and analyzes the user's goal and searches for a plan to realize the goal. Then, it suggests possible com-

Requests for reprints should be sent to Geunbae Lee, Department of Computer Science and Engineering, Pohang Institute of Science and Technology, P.O, Box 125, Pohang, 790-600, Korea. E-mail: bdragon,gblee @ vision.postech.ac.kr

71

72

W. L Lee and G. Lee ]

Case-base

must be used in the system's input. Using the hierarchical rule base and the derivational analogy, the input specifications are transformed into shell scripts. To our knowledge, however, no previous systems combine natural language parsing with automatic programming in a uniform methodological framework. Our aim is to develop a mixture of UC and APU in a synergetic way based on the case-based reasoning principles (Bain, 1986; Hammond, 1989; Riesbeck & Martin, 1985; Riesbeck & Schank, 1989; Simpson, 1985).

I

3. CASE-BASED REASONING FOR PARSING AND AUTOMATIC PROGRAMMING We developed a methodology to combine natural language parsing with automatic progranm,ng within a case-basod framework. Case-based reasoning (CBR) provides a nice framework for combining natural language parsing with planning, which is a generalized form of automatic programming, because CBR views both parsing and planning as a memory-based task (Hammond, 1989; Riesbeck & Martin, 1985; Riesbeck & Schank, 1989).

FIGURE 1. System architecture.

mands for the user. UC's work is focused on the natural language understanding that includes parsing, goalplan analysis, user modeling, and natural language generation. However, UC does not have an automatic programming ability so it can only process the sentence that can be realized by a single UNIX command. Automatic programming in UNIX (APU) (Harandi & Bhansali, 1989) is an automatic programming system in the UNIX domain. APU adopts derivational analogy (Carbonell, 1986) as the problem solving technique. However, a predefined specification form

3.1. Analyzing Natural Language Commands Using Case-Based Parsing Case-based parsing (Riesbeck & Martin, 1985; Riesbeck & Schank, 1989) is the idea of parsing by rernember-

m-query

I

ou~/1,~'list'°ut ~



" (a.)> m-list/'s

m/ist/of• m:attrs , 4

7 " = a>l l ~ " < whoseI'restl

m,constrFhose

m-conMr/sent's

m-sim~le-obj

~rest m-attr

first

m-st/attr

~constr/sen

< (first) ts 2reate m-I~ater/se~t

m-attr



m-constr/wlth

< (first]~and(rest)> d/sent

m-less/sent

m-value

FIGURE 2. Linguistic memory.

Natural Language to Shell Script

73

plex

T

m-list

\ line

m-attr

/

m-flle4ttr

m-action

m-dir-attr

/2?-._.

m-user-attr

~ t e

ten

tute

chgrp

©hown

chmod

nanle

,.-.~

m-o~ re-.o, J , - i , ~ r~r

T \,

m-greater

m-eq

,-r,~

m-,~.,~

m-in

m- tm

FIGURE 3. UNIX object memory.

ing. Parsing from cases ~ remembering past instances of language use so that they can be recognized again, and remembering past conceptualizations so that they can be recalled. Case-based parsing is very different from the previous conceptual analysis approach (Bimbaum & Selfridge, 1985; Dyer, 1983; Lytinen, 1984). The issues of memory organization, indexing, and memory search are of great importance to a case-based parser because it must operate within an existing memory model. The parsing task is defined as a memory search problem. Concepts are not constructed from pieces derived from the input. Instead, concepts already exist in the memory that fit to the needs of the understander. The task is to use the clues in the input to locate the most relevant concepts and modify them as needed to reflect the differences between what is seen and what is already known. Because the case-based parser makes use of memory, it can use expectations derived from the memory and these expectations guide the parsing process. Instead of relying on the memory to disambiguate possible interpretations after parsing, a case-based parser uses the goals and expectations in the memory to disambiguate the input during

the parsing process. 3.2. Generating UNIX Shell Scripts Using CaseBased Planning Just like the case-based parsing, case-based planning (Hammond, 1989) is the idea of planning by remem-

bering. When a surgeon approaches an operation, he does not build his own course of actions pieCe by piece out of a set of primitive steps. He recalls the past successful operations in the similar situations and modifies his behavior to suit the new situation. Case-based planning is based on the same idea. There are four subtasks in the case-based planning: how to retrieve the most relevant case to the input specification, how to adapt the retrieved case, how to recover from an adaptation failure, and how to store a solved case. The retrieval of the best case is an essentiai requirement for the success of the whole planning. The adaptation is closely related to the constituents of a case. Two methods are currently known: transformational adaptation and derivational adaptation (Carbonell, 1986). In the transformational adaptation, a case has only the final results and the duplicated decision of what to change is made. On the contrary, in the derivational adaptation, a case has full intermediate information and uses general problem solving facilities. The failure recovery depends on the adaptation method. In the transformational adaptation, a complicated reasoning process is required. However, in the derivational adaptation, the behind general problem solving mechanism does the failure recovery. In DINX, we used the derivational adaptation as the adaptation method and the rule-based reasoning

W. L Lee a n d G. Lee

74

m-UNiX-plan 0

0

ITS

m-simple

l

m - o b / m - c~"' o n s t ":

r m~-pla~

m-case/in-air

~-m-ch~nge.i2

i - m - rul~l, i - m d -i s / ~- f . i 2 . .

attrs ob"

m-case/ih-file

-m-list-

dir.i4,

m-casOoutAist

.

i - m-constr.i7,

restl/t

i-m-~t/plan.il

rest fi:st~f.fl ~

ow~l :(2~rsti-m-in,l;:iTr~:li:i:t Jr. ~taCt-on-files.itJ FIGURE 4. UNIX plan memory.

as the general problem solving mechanism for the failure recovery.

3.3. K n o w l e d g e Sharing D u r i n g Parsing a n d Planning In a fixed domain, a parser and a planner have considerable amount of knowledge in common. In a UNIX domain, the knowledge about the objects and the commands is shared. The parser uses this knowledge to check the semantic validity of the input and the planner uses it as its implementational vocabulary. We designed the separate knowledge bases for the natural language, UNIX objects and commands, and solved cases and rules for the shell programming. The parser and the planner share the knowledge base for the UNIX objects and commands. The basic unit of the knowledge bases is Memory Organization Packets (MOPs) (Schank, 1982). A MOP has inheritance links and packaging links. The inheritance links specify the generalization or specialization relations, and packaging links specify the slotfiller relations in the frame-based representation (Minsky, 1975). The filler of each slot is also a MOP. An abstraction network with inheritance links and a packaging network with packaging links are constructed and spliced together. Packaging links tie the co-occurring MOPs together. A MOP can be attached to an index pattern, which guides the parsing.

4. S Y S T E M A R C H I T E C T U R E Figure 1 shows the system architecture of DINX. DINX consists of three processing modules: a casebased parser, a transformer, and a case-based planner. There are four memories (knowledge bases): linguistic memory, UNIX object memory, UNIX plan memory, and UNIX rule memory. The linguistic memory is a dynamic memory of index patterns. The index patterns direct the expectations during parsing. The UNIX object memory is where all the UNIX objects, their attributes, and the shell commands reside. The UNIX plan memory is the storage of the plans (cases) that have the problem solving steps as their contents. Cases in the UNIX plan memory are grouped along the similarities and differences between them. The parser uses the linguistic memory and the UNIX object memory to check the domain and linguistic constraints. For example, "list the name and owner of the user whose size is greater than 10K" is an invalid command, since the and the together can only be attributes of a not of a The parsed result, which is a MOP, is transformed into a case that only has a matching header. The planner retrieves the best case from the UNIX plan memory and solves the input using the best case. The planner uses the UNIX plan memory, the UNIX rule memory and the UNIX object memory. The UNIX object memory is used to get an attribute of a UNIX object during plan (shell script) generation and the UNIX rule mem-

name owner file, user.

Natural Language to Shell Script

75

i m rule.1

~~ut~

input

onstr$

mo-b;O;3 , , m hier o b j ~ s T n S t r . 6

mob'

roc i_m_proc.t;

m in_4 FIGURE 5. UNIX rule memory.

ory is used to recover from the adaptation failure. Next are the detailed explanations on the four memories and the three processing modules.

4.1. Linguistic M e m o r y

The linguistic memory is where the linguistic knowledge resides. Part of the linguistic memory is shown in Figure 2. The linguistic memory consists of MOP nodes such as the m-query with inheritance links (thick lines) and packaging links (arrows with slot names). The m-query is the most abstract MOP in the abstraction hierarchy, and represents a user's query. The mquery has many specializations that represent possible query classes. One of the classes, the "to list out something," the MOP m-list-out, is shown in Figure 2. The MOP m-list-out has an index pattern (list (output) (constrs)), which says that "list" is expected and then (output) and (constrs) slots are expected. If all of these are satisfied, the m-list-out is activated. We extended the MOP in order to handle recursive constraints. An index pattern can be seen as a production rule in a semantic grammar. However, in the original model of direct memory access parsing (DMAP; Riesbeck & Martin, 1985), the index patterns cannot be recursive and even if they are recursive, only the primitive one is processed correctly. The recursive constraints are shown in the m-constr/sent's MOP. The m-constr/sent's represents " a n d - " or " o r - " connected multiple constraints such as "size is greater than 10K and permission is 477".

4.2. C a s e - B a s e d P a r s e r

Case-based parsing is performed by keeping a set of expectations and activations of index patterns. An expectation in the set can be advanced, removed, or activated. When the first concept of an expectation is matched with the input, the next concept in the expectation is predicted. When the first concept of an expectation is not matched with the input, the expectation disappears. When all the concepts in an index pattern are satisfied, the pattern's MOP is activated.

Here's an example. When parsing the command "list the name and owner of the file whose size is greater than 10K," initially the m-query is expected. This expectation goes down the abstraction hierarchy shown in Figure 2 and new expectations including the index pattern of the m-list-out are generated: ( (list (output) /constrs) ) m-list-out) ........... ( 1 ) The m-list-out in Equation 1 indicates the source of the expectation. The underlined is the current index pattern of the expectation. When the "list" is matched with the list, Equation 1 is advanced and all the other expectations that do not begin with list disappear: (((output) (constrs)) m-list-out) .................. (2) The (OUtpUt) slot of the m-list-out is the m-list/lang and the m-list/lang has the m-list/of and the m-list/ 's as their specializations. The expectation goes down and generates the following two expectations: ((((the (attrs) of (obj)) m - l i s t / o f ) (constrs)) mlist-out) ............................................................... (3) ((((the (obi)'s /attrs)) m-list/'s) (constrs)) mlist-out) ............................................................... ( 4 ) Now, there are two expectations. After matching the " t h e " , two different slots are expected: ( ( ( ( ~ ) m-list/o f ) (constrs) ) m-listo u t ) ...................................................................... (5) ( ( ( ( ~ ) m-list/'s) (constrs)) m-listo u t ) ...................................................................... (6) Since there are two specializations for the m-attrs, the (attrs) slot of the m-list/of, the following expectations are produced at the next step: ( ( ( ( m - a t t r of (ob i ) ) m - l i s t / o f ) (constr)) m-listo u t ) ...................................................................... (7) ( ( ( ( ( ( m - a t t r and (rest)) m - s t / a t t r ) of (obj)) mlist/o f ) (constrs)) m-list-out) .......................... ( 8 ) ( ( ( ( m-simple-obj's ( attrs ) ) m-list/'s ) ( constrs ) ) m-list-out) ........................................................... (9) On seeing " n a m e " , Equations 7 and 8 are advanced and Equation 9 is removed since the name is an instance of the m-attr, but not of the ~ (see section 4.3.)" ( ( ( ( o f ( o b j ) ) m - l i s t / o f ) (constrs)) m-list-out) ........................................................................... (10) ((((((and (rest)) m-st/attr) of (obj)) m - l i s t / o f ) (constrs)) m-list-out) ....................................... ( I I ) Next input " a n d " rejects Equation 10 and advances Equation 11: ( ( ( ( ( ( ( r e s t ) ) m-st/attr) of (obj) m - l i s t / o f ) (constrs)) m-list-out) ....................................... (12)

Finally, (res=_At)is satisfied by the "owner" and the mst/attr is activated. An instance of the m-st/attr with the name and the owner as its (first) and (rest) slots is constructed. The rest of the expectations in the list

76

IV.LLeeandG.Lee i-m-list-out.17

i-m-lis/of.13

attr/

lobj

i-m-st/attr.l I ftle.12

i-m-constr/whose.16

firs¢

~st

recursively i-m-greater/sfnt.15

firs¢ ~est

firs/ lrest name

All the hierarchies play roles in retrieving a case so that similarity between cases are determined by the similarity between objects, attributes, and actions in the hierarchy. The objects, attributes, and actions are also used as the implementational vocabularies.

owner

10K

size FIGURE 6. Parsed query.

are processed and an instance of the m-list-out is generated as the final result. 4.3. UNIX Object M e m o r y

Objects, their attributes, and shell commands in the UNIX domain make the UNIX object memory (Figure 3). All the objects are specializations of the m-obj. The m-obj is specialized to the m-complex-obj and the m-simple-obj. The m-simple-obj is a class of real objects in UNIX domain. The m-complex-obj is a structured object of the m-simple-obj. The m-simpleobj is refined as the m-file-obj, the m-user, and the m-text. The m-file-obj has (name), (owner), (size), (permission), (chgrp), (chown), (chmod), etc. as its slots. These slots have their implementations in the UNIX shell scripts. These slots are inherited to the file and the dir. All the UNIX actions on the objects are classified as the m-action and all the attributes of the UNIX objects are classified under the m-attr. Constraints also have a hierarchy with the m-constrs as the most abstract MOP, and each constraint has its own implementation in the UNIX shell scripts.

4.4. Transformer The parsed results in the linguistic memory are passed to the case-based planner. For the planner to solve the problem, all the slots of a case header must be filled in. But user's query seldom satisfies this condition. For example, the command "list the name and owner of the file whose size is greater than 1OK" does not specify what the input is and where the file comes from. In this case, it is reasonable to assume that the input is the current working directory and the file is in the directory. The transformer performs the necessary conversions between parsed results and input specifications for the case-based planner. 4.5. UNIX Plan M e m o r y

As shown in Figure 4, a case has (input), (output), (constrs), and (implementation) slots. The (input), (output), and (constrs) slots are used together as a matching header of the case. The (implementation) slot has the decomposition of the case into subcases. Each subcase has data and control dependency represented by the (data) and (control) slots. A case in the UNIX plan memory has an implementation hierarchy whose lowest level is expressed in the primitive UNIX shell commands. Each decomposition is the result of a rule application. A solved case also has the (rule) slot, which remembers the applied rule. Similar cases are grouped into an abstract case and an abstraction hierarchy exists.

i-m.list-out.17

t'-m-h"

attr i-m-st/attr.ll

.

e

obj

i-m-constr/whose.16

rest

rest

r e\ ~l~~rr~Jr lres t

file.12-,4:----_ i-m-in.14

fi~~e o~re:t first

first

ecursiv y

i-mrand.18

i-m-greater/s~t.15

first / size FIGURE 7. Transformed case-header.

est 10K

NaturalLanguagetoShellScript

77

dir i-m-Iis/of.i2~~i-m-rule. 1 i-m-constr.i5 °fi!.8 ~ttrS~o~vne r~

i.mteS2ter.i3

res~i.m!Sist4~i.~m2ela'~tlfi:~ze !2: FIGURE 8. Retrieved case.

4.6. UNIXRuleMemory A shell programming rule is very similar to a case. A rule has (input), (output), and (constrs) slots. The differences between a rule and a case is that the rule's (input), (output), and (constrs) slots are more abstract than those of the case and the rule has a procedure to be applied rather than a rule-application history and a decomposition hierarchy. Figure 5 shows a rule. 4.7. Case-Based P l a n n e r As indicated in section 3, there are four subtasks in the case-based planning: retrieval, adaptation, failure recovery, and storing. We focused on the first three subtasks. When an input specification is given to the planner, the most special abstractions of the input are distinguished. Among the instances of the distinguished, the most similar one is retrieved. The similarity between the input and the case is computed using the hierarchical matching. In derivational analogy, adaptation is replaying the history of the best case (Carbonell, 1986). The transformations between the input specification and the shell script are achieved as a result of the derivation replay. An adaptation failure occurs when an invalid transformational rule is selected as a result of the differences between the input and the best case. In this case, the UNIX rule memory is searched and the searched rule is applied to the input. If the application succeeds, the decomposed subproblems are solved one by one using the case-based approach. 5. F R O M N A T U R A L L A N G U A G E T O S H E L L A S A M P L E RUN

SCRIPT:

The DINX system is implemented in a Common Lisp environment and is being reimplemented in C. We have tested several natural language commands including the following one.

Let's trace how DINX processes the input: "List the name and owner of the file whose size is greater than 10K recursively." Parsing goes on as explained in section 4.2., and the instance of the m-list-out is constructed. The parsed result is shown in Figure 6. The parsed query is transformed into the case header. The input slot of the query does not exist, so the file's domain cwd is assumed as the input. An instance of the constraint m-in with file. 12 and cwd as its slots is added to the i-m-constr/whose. 16, And each attribute's object slot is filled with the appropriate object in the query. These results in the case header shown in Figure 7. After that, the transformed case header is passed to the case-based planner. The case i-m-list-out.17 become an instance of the m-case/in-dir and the m-case/ out-list. Then similarities between other instances of these MOPs and the i-m-list-out. 17 are calculated. The i-m-list-out.il is retrieved as the most similar case (Figure 8), which is for the command "list the owner of files greater than 100K." The i-m-list-out.il has a history of rule applications and the decomposition rule i-m-rule.1 is the first one. This rule is the first candidate to be applied to the current problem. It says that to solve the problem, solve two subproblems: to get the list of all the files in the directory, and to check each file in the list and do the required actions on the file. However, because the constraint re.cursively must be resolved earlier than the m-in constraint this rule fails. After the failure, UNIX rule memory is searched and the i-m-recursive-rule is retrieved as the next candidate (Figure 9). This rule says that to solve the problem, solve a subproblem where the recursive constraint is removed and apply the result shell script to the subobjects of the original input object. Because the cwd is a specialization of the m-hier-obj (a class of hierarchical objects which have subobjects), this rule can be applied. This rule succeeds and results in the implementation shown in Figure 10. The first problem, i-m-unixplan.23, is to apply i-m-list-out. 17 to all the subdirectoties of the cwd. The second problem, i-m-unix-plan.24,

i m_recursive le m_hierobj m_obj m constr.9 i_m_proc.10

--~rst

recursively FIGURE 9. Selected rule.

78

W. L Lee and G. Lee i-m-st/plan.25

fiJ

controlN ~

i-m-unix-plan.2J-""'l~

t

i-m-unix-plan.24

/

i.am~, d ! ~ l

firs1~

out.17 res~

rest . ~rest t ob ~e [ |.m.grea er file.12 ~ n r s

/

\

Vrs,[I

i-~-st/a~tr.1l

'~en~"is 4

}ii27

i-m-,n.22

FIGURE 10. The (implement) slot of the input.

For the i-m-unix-plan.24,the i-m-list-out.il is retrieved again. The i-m-list-out.il'srule, i-m-rule.l, is appliedto the i-m-unix-plan.24and succeeds.Afterthe applicationof the i-m-rule.1, the i-m-unix-plan.24has an (implementation)slot very similarto the i-m-listout.il's. The i-m-list-out.il's (implementation)slot,

is to list the name and the owner of the files > 10K in the cwd. The two subproblems, i-m-unix-plan.23and i-munix-plan.24, are solved using the UNIX plan memory. For the i-m-unix-plan.23,the i-m-list-out.il is retrieved. i-m-st/plan.1 dir.flles,$ inp

data ~

act..on-flles.18

input inp

i-m-in.14-tm-flle.9

o

/ \

ut

le

onstrs

flle.lO o w n e r

/

i-m-~ater.13

i-m-sl/plan,2 P-m-'in.10

size

Ck generate

i-re-,s/or.6 o

re v

file.7

~°'~l /

10~K

i-m-st/plan.3

,q

V i,~m~ f ...,~,~-:-tllter

l-m-~pla..4

st

! ~'~



input



P "

~

i.m.-greater.13 flle.3.ql----accumulate

i o

i2 attr

file

i

owner

]a

i-m-sl/p n.5

nerate ment

"endif"

FIGURE 11. The (implement) slot of the case.

"

"

Natural Language to Shell Script

set i m list 22 ,, "/bin/is-AF1 I sed '/[^/]$/d' foreach dir_10 ($i_m list 22) set dir 10 = "/bin/Is -is Stile"

79

works will be focused on ( 1 ) plan indexing, (2) parallel natural language parsing (case-based parsing), and (3) large knowledge bases.

if (1) then i m list out 7 dir_10[5] end set i m list 23 = "/bin/is -AF1 I sed 'A/$/d' foreach file ($i_m list 23) set file = "/bin/Is -Is Stile" if ($ffie[1] > 10) then echo Stile[5] Stile[4] else endif end FIGURE 12. Result shell script.

shown in Figure 11, is the primary source of the decomposition rules. These two cases are so similar that the rules of the i-m-list-out.il (i.e., get-sub-rule and out-list-rule) solve the i-m-unix-plan.24 correctly. The i-m-unixplan.23 is solved similarly. Traversing the implementation hierarchy along the data and the control dependency results in the following shell script (Figure 12). 6. C O N C L U S I O N An efficient and user friendly natural language interface system to UNIX is introduced. We argue that an efficient natural language interface system should be augmented with automatic programming ability. We present DINX to demonstrate that case-based reasoning can be a unifying framework to combine natural language parsing with automatic programming. In DINX, a single natural language command is automatically translated into a UNIX shell script, so that an ordinary user does not need to invent their own procedures to get the desired results. The contribution of DINX are: ( 1 ) integrating parsing and automatic programming for an intelligent interface, (2) extending case-based reasoning to natural language processing and UNIX programming, and (3) solving the failure recovery problem of the case-based reasoning using the rule-based reasoning. The future

Acknowledgment--This project was supported by KOSEF grant #923-1100-011-2 to G. Lee. We also thank the anonymous reviewers of the manuscript for their valuable suggestions.

REFERENCES Bain, W. M. (1986). Case-based reasoning: A computer model of" subjective assessment. PhD thesis, Yale University, New Haven, CT. Birnbaum, L., & Selfridge, M. ( 1985 ). Conceptual analysis of natural language. In R. C. Schank & C. K. Riesbeck (Eds.), Inside computer understanding (pp. 318-353). Hillsdale, NJ: LEA Press. Carbonell, J. G. (1986). Derivational analogy: A theory of reconstructive problem solving and expertise acquisition. In Machine learning: An artificial intelligence approach (pp. 371 - 392), Vol. II. San Mateo, CA: Morgan Kaufmann. Dyer, M. G. (1983). In depth understanding. Cambridge, MA: MIT Press. Hammond, K. J. (1989). Case-based planning: Viewing planning as a memory task. Boston, MA: Academic Press. Harandi, M. T., & Bhansali, S. (1989). Program derivation using analogy. Proceedings of the I I th International Joint Conference on Artificial Intelligence (pp. 389-394). Detroit, MI: Morgan Kaufmann. Lytinen, S. (1984). The organization of knowledge in a multilingual, integrated parser (Res. Rep. 340). New Haven, CT: Yale University. Minsky, M. (1975). A framework for representing knowledge. In P. Winston (Ed.), The psychology of computer vision. New York: McGraw-Hill. Rich, C., & Waters, R. C. (1988). Automatic programming: Myths and prospects. IEEE Computer, 3( 1 ), 40-51. Rich, C., & Waters, R. C. (1990). Programmer's apprentice. Reading, MA: Addison-Wesley. Riesbeck, C. K., & Martin, C. E. (1985). Direct memory access parsing (YALEU/DCS/RR 354). New Haven, CT: Yale University. Riesbeck, C. K., & Schank, R. C. (1989). Inside case-based reasoning. Hillsdale, NJ: LEA Press. Schank, R. C. (1982). Dynamic memory: A theory of reminding and learning in computer and people. Cambridge, MA: Cambridge University Press. Simpson, R. L. (1985). A computer model of case-based reasoning in problem solving: An investigation in the domain of dispute mediation (Tech. Rep. GIT-ICS-85/18 ). Atlanta, GA: Georgia Institute of Technology. Wilensky, R., Arens, Y., & Chin, D. (1984). Talking to UNIX in English: An overview of UC. Communications of the ACM, 6(3), 574-593.