Designing CALL programs for communicative teaching
This article describes three stages in the development of CALL programs to fit the communicative approach to language teaching, which is here understood as an approach that emphasizes meaningful interaction and information exchange. The three stages are exemplified by programs called Escape from Utopia (based on an EUZA keyword-matching technique). Shannon's Game (a syntactic parser approach that uses PROLOG), and Station (an information processing approach that also uses PROLOG).
The three stages exemplify progressively deeper ways of handling language by computer. The article suggests that the first stage superficially allows students to interact meaningfully with the computer, and that keyword matching has severe limitations and is incapable of further development The second stage, parsing, is considered an improvement on traditional teacher techniques rather than a contribution to the communicative approach. The third stage is regarded as more fully usable within communicative methodology, since it requires programs that represent and handle information as well as parse structure.
The article concludes that there is no necessary incompatibility between the communicative approach and CALL, even if considerable development is needed.
Introduction
An account of Computer Assisted Language Learning (CALL) concludes that the connection between CALL and language teaching is at present tenuous (Cook 1985a). The conclusion was that while teachers today commonly expect students to learn by understanding meaningful messages, or by communicating information to one another, CALL programs mostly assume that they learn by drilling or by consciously mastering grammatical rules: the ideas of language learning reflected in CALL and those reflected in communicative language teaching are therefore out of step. This article tries to bridge this gap by developing the links between CALL on the one hand and the communicative approach to language teaching on the other.
The communicative approach is a broad umbrella ranging over ideas as various as those of Brumfit (1984), Littlewood (1981), and Widdowson (1978). Here, the approach is understood with reference to two principles: one is that the students engage in meaningful interaction with each other in the classroom; the other is that this interaction involves them in information exchange of one kind or another. These principles are used in many teaching activities, and the discussion here will concentrate on two typical communicative techniques, found in many discussions such as Littlewood (1981) or Revell (1979): information gap games, in which the students devise their own strategies for overcoming a difference in information set up by the teacher, as in the widely used game in which two students have to find out the similarities and differences between two pictures; and functional roleplay activities, in which the students act out a real-world situation they are likely to encounter and the type of information exchange they will have to use, as in simulated situations involving customers and shop assistants, passengers and travel clerks, or doctors and patients.
The way of accommodating CALL to communicative teaching suggested here consists of improving its ability to interact with students and to handle information. This means drawing more on the computer's ability to handle human language than CALL has actually done. The article outlines three progressively deeper ways of handling language by computer, illustrated by specimen programs. As well as describing their teaching use, some time is spent giving the reader an idea of how they work, so that he or she may see their limitations and potential; a more general account of the computing background can be found in Cook and Fass (1986) and Cook (1987).
The ELIZA Approach
Escape from Utopia (Cook 1984a) is a spy game in which the students have the goal of escaping from the city of Utopia within 24 hours. The students have to work out a plan of escape and must remain undetected long enough to put their plan into operation. The game starts in the main square of the city; the students decide which places they want to go to—the restaurant, hotel, railway station, and so on. A map appears on the screen with symbols for the students' location and for that of a patrolling police agent. They move around the map by typing commands into the computer:
Student: Turn left.
Computer: OK. [The students' symbol moves one space leftward, the police agent moves one space nearer.]
S: Go east.
C: Impossible. [There is a building in the way. The students' symbol doesn't move, but the police agent comes one space nearer.]
S: Right.
C: No verb. [The police agent moves one space nearer.]
And so on, until the students reach the destination or are caught by the police.
When the students arrive, they engage in dialogues appropriate to the situation; if they are at the restaurant, the following dialogue could ensue:
C: You go into an expensive restaurant. You sit down at a table and a man comes up to you and says:
C: Can I help you?
S: I'd like something to drink, please.
C: What would you like?
S: Some beer.
C: I'm sorry. We are not allowed to serve alcoholic drinks before six. Can I get you something else?
S: Yes. Could I have a cup of coffee?
C: Certainly. Black or white?
S: White, please.
C: You sit waiting. The waiter comes with your drink.
C: Here is your coffee.
S: Thank you very much. '
C: You sit drinking your coffee. Press C when you have finished.
On the surface this seems like the usual dialogues familiar in functional and situational textbooks. However, the dialogue here is flexible rather than predetermined. On the one hand, the details of the restaurant and the waiter's remarks are never exactly the same twice running; on the other, the computer adapts its language to whatever the student types in—dealing appropriately with food or drink (ranging from a cup of coffee to a four course meal). The students lose points by making mistakes in English, such as not using 'please', or by contravening the conventions of Utopia: for instance, the word 'blue' is taboo because of its associations with a banned political party.
The computing technique that forms the basis of Escape is keyword matching. When the students type in Turn left, the computer scans the sentence to see if any of the words match a list of 'keywords' it has stored, 'turn, move, . . . right, left, up, . . .'. If it finds a match, it works out if the move is possible in terms of the current state of play and then moves the symbol; Turn left means matching 'turn' and 'left', finding which space is left of the students' current position, checking whether it is empty, and then moving the symbol there. The process is matching the input against keywords and following preset actions for each keyword; if it fails to find a match, it displays messages such as 'No verb' or 'No direction'. The keyword-matching principle is used in most computer adventure games such as The Hobbit (1983).
The dialogue situations in Escape take keyword matching a stage further in what is known as an ELIZA program (Weizenbaum 1966). In the restaurant scenario the student types Could I have a cup of coffee please? And the program searches its stock of keywords to find any matches. Having matched coffee, it looks for a preset message and finds Black or white?. If the student had typed tea, the appropriate message would have been With milk?; whisky would have prompted With ice?, and so on. Again this is a mechanical process of finding a keyword and taking appropriate action, here displaying a message. As well as keyword matching, ELIZA programs make use of the input in various ways. They may store the students' remark and give it back to them at a later time; I'm here on holiday later becomes Earlier you said you were here on holiday by adding Earlier you said, changing I'm to you were and ending with a repetition here on holiday. Or the programs may store the input to use in particular routines; the police interrogation in Escape has an insult routine in which the students' nationality is combined with various patterns such as You . .. fool! or Why do .. . people always tell lies? The combination of these techniques gives a reasonable impression of conversation, as we see above. Many people using ELIZA credited it with amazingly perceptive powers (Weizenbaum 1976). However, this is little more than an illusion; the program is mechanically looking for strings of letters and producing other preset strings of letters in return.
The activities in Escape are then closely related to the communicative techniques mentioned above. In the map section the students are engaging in a computer version of an information-gap game, very similar, for example, to that described in Krashen and Terrell (1983) and many other sources; the computer responds to their attempts to guide the spy round the city streets, just as their partner responds in the classroom version. The dialogues put the students in simulated tourist situations—what to say when buying things in a shop, or ordering drinks in a cafe; again this is parallel to functional role play. The spygame context of Escape is intended to motivate and entertain with its flavour of an adventure game. Individual students can use it on their own; the game is never quite the same on two occasions or for two different students. It may also be used with small groups of students or with the entire class; the students have to decide what the character should do, and a spokesperson or the teacher types in their input; here the value comes not just from the program itself but also from the discussion it stimulates among the students.
Surprisingly ELIZA techniques have seldom been utilized in CALL, though the technique is easily accessible in the literature and adaptable to microcomputers (e.g. Krutch 1981). ELIZA techniques can be used with other teaching exercises. Chatterbox (Cook and Hamilton 1984), for instance, interviews students for admission to a university; the teacher can set up alternative situations by adding suitable keywords and messages, for example changing the interview to a hospital or a chemist's shop.
ELIZA programs go some way towards CALL material that handles language. They meet the communicative principle of meaningful interaction in that the students interact within a limited situation; the students' partner, however, is a computer rather than another student. ELIZA programs also meet the principle of information exchange by requiring the students to use particular types of information. The students' attention is then focused on what they are doing with language, rather than on language forms: the activities seem very similar to conventional communicative techniques.
What is wrong with them is not so much their teaching use as their severe limitations in computing terms. One problem is their very strength; while they produce some kind of response whatever the input, there is no check on its grammaticality or meaningfulness; teachers and students may become justifiably frustrated by a program that accepts You estupido by blandly answering Do go on. Improving the realism of the simulated conversation also becomes more and more unwieldy; the PARRY program needs some 10,000 matching patterns to model a paranoid patient, for instance (Colby 1975). ELIZAs are also superficial; they do not recognize syntax or meaning, they match strings of letters. ELIZA programs therefore represent a dead end rather than a growing point; readable accounts of their failings can be found in Schank and Childers (1984) and Weizenbaum (1976). While programs such as Escape show that typical communicative activities can be incorporated in CALL, their lack of subtlety means they should be treated as amusement rather than as serious teaching.
The syntactic parser approach
To go beyond this, let us see to what extent keyword-matching programs can deal with syntax. Shannon's Game (Cook 1985b) requires students to guess words of a text in sequence from start to finish. Students may ask for clues about the next word at any time. Suppose the students have so far guessed some of the first words of a beginner's text:
C: Alec Guiness is a famous film star.
C: Clue: pronoun
S: He
C: Right. Alec Guiness is a famous film star. He
C: Clue: auxiliary
S: can
C: Wrong. Two guesses left.
S: is
C: Right. Alec Guiness is a famous film star. He is
C: Clue: content word.
S: young
C: Wrong. Two guesses left.
S: American
C: Wrong. One guess left.
The actual screen display keeps all the text guessed so far on the screen, rather than repeating it as here. There is considerable choice in the way students can tackle the text. Apart from choosing a text, they may request four different levels of clue. Level 1 tells them whether the next word is a 'content word' such as English, or 'a structure word' such as is. Level 2 tells them the type of structure word—'preposition', 'article', 'auxiliary', and so on. Level 3 gives them help with word endings; they are told if the word ends in s or ing, or er, etc. Level 4 gives more specific clues such as 'present continuous', 'passive', or 'proper name'. The more help they ask for, the fewer points they can score. The students also decide whether to guess content words only, structure words only, or all the words in the text. The teaching aim is to develop the students' feel for text structure; the exercise can be done individually or by groups of students who discuss the answers they should give, with or without the teacher's help. The teacher can add any text he or she likes to the program at any level of difficulty.
The program does not depend upon the teacher pre-analysing each text; this is done by the computer through keyword matching. It recognizes a set of keywords, namely 206 structure words, and has preset 'clues' that it prints according to the level of help requested. So at Level 1, if the computer matches the word as a structure word, it prints out the message 'structure word'; if it can't match the word, it prints 'content word'. At Level 2 it has a preset message 'pronoun' when it encounters any of a list of pronouns, and the same for other word classes. At Level 3 it looks for word endings and has messages to print whenever it matches ing, or er. At Level 4 on the one hand it provides more detailed messages such as 'Subject pronoun' for I versus 'Object pronoun' for me; on the other it works out tenses—if it finds an ing ending and the preceding word was is or are or am, it suggests 'present continuous'. While Shannon's Game appears to use syntax, this too is an illusion; it is looking for keywords or endings, i.e. strings of letters in the input, and producing preset messages. It therefore tends to make mistakes; thus it calls red a. past tense, and claims that ring is an '-ing word'.
Keyword matching is an ineffective way of looking for syntax, since understanding grammatical structure involves more than matching strings of letters and recognizing structure words. How could the computer better deal with the identification of grammatical structure? This requires a 'parser'—a program that recognizes the syntactic structure of sentences. The basic process is to invent a possible structure for a sentence and to see if it fits the one that has been typed in; if the guess doesn't fit, the program goes on inventing structures till it succeeds or it gives up.
Suppose the input is The man sees the train. The program starts by guessing that this is a sentence consisting of a noun phrase and a verb phrase; it then guesses that the noun phrase will have a determiner and a noun. It now turns to the actual sentence and checks whether the is a determiner; it succeeds, so it checks whether man is a noun, which again succeeds. It goes back to the verb phrase, which it guesses will consist of a verb and a noun phrase. It checks whether sees is a verb and succeeds. It guesses that the second noun phrase has a determiner and a noun, and successfully matches the and train. It has checked the whole of the sentence against its guesses and has therefore 'parsed' the sentence. Matching is now the final step, rather than the whole process.
This parser can be put in the form of the following 'rules':
S — NP VP
NP — Det N
VP ->- V NP
N —»• man, John, bomb, train, . . .
Det -»- the, a, . . .
V —- leaves, goes, sees, . . .
To those familiar with generative grammar, these rules are instantly recognizable as a conventional phrase structure grammar. Such grammars can be converted into parsers through part of the computer language PROLOG known as 'grammar rules' with only minimal changes, e.g. S —> NP VP becomes s —> np,vp.
What happens when the parser's guess is wrong? Let us add the rule for English intransitive sentences that have a verb but no object, i.e. VP—> V. Suppose the parser is given the train leaves. It starts as before by hypothesizing that this is NP VP, and that the NP is Det N, all of which succeed. Now it guesses that VP is V NP, the first VP rule. It succeeds in checking leaves as a verb, but there is no NP left to match: the rule VP—>V NP has failed. So it turns to the second rule VP —> V; it tries to match leaves as a verb, succeeds, and completes parsing the sentence. If the program does not succeed in its first guess, it goes back to the point where things started to go wrong and tries again with another rule. It keeps doing this until it gets it right, or until it runs out of rules and fails to parse the sentence.
Technically the type of parser outlined here is top-down (it goes from the sentence down to the words, rather than vice versa) and depth-first (it follows one item all the way, rather than looking at them all simultaneously). Many other kinds of parser are possible; a useful introduction can be found in Winograd (1983). While few parsers deal with much of the syntax of native speakers, a CALL parser can be less complex because the student's grammar can be considered in many respects a 'simplified' form of the language. The task does, however, demand a high-level computer language such as LISP or PROLOG rather than the languages mostly available on microcomputers.
Such parsers can be used with any CALL exercises that involve syntactic structure. A major use is for grammatical correction. In a program described in Pulman (1984), students explore their knowledge of English by testing out their sentences; they ask questions and the computer answers them or gives them feedback. FROG (Imlah and du Boulay 1985) uses a combination of top-down and bottom-up parsing in PROLOG to check students' sentences in French for various types of grammatical mistake such as agreement. Parsers can also be used in drills to check the students' answers in a more exhaustive fashion than is allowed by preset answers and permitting a range of possible answers to be given, all equally correct. A further use is with text-guessing exercises of the Storyboard type (Jones and Higgins 1984). As in Shannon's Game, these may be extended by giving the student help with grammatical clues; a parser can provide more detailed and accurate grammatical clues than the keyword program described above. Though as yet little used in CALL, grammatical explanation techniques could also be linked to a parser that produces or analyses sentences according to the rule being taught, and also draws visual diagrams of the structure of the sentence. Finally a more ambitious use is to create exercises; the program described by Markosian and Ager (1983) invents the drill itself from a parser and a dictionary according to the teacher's instructions.
Syntactic parsers therefore tend to make existing CALL techniques more sophisticated, mostly by providing superior assessment and correction of the student's input. For those who are concerned with grammatical correction, grammatical explanation, or drills, this may in itself be a step forward. But a parser can contribute little directly to communicative teaching, since it is concerned with grammatical form, rather than with interaction or information; it can itself add little to information-gap exercises and functional role plays.
An Information processing approach
A program called Station (Cook 1985c) shows how a parser can be extended to facilitate communicative CALL programs. In Station students have dialogues with a local railway station (in this case, Colchester in Essex). Students enquire when trains leave, what platform they leave from, how much the tickets cost, etc.
C: Hello. British Rail, Colchester.
S: Could you be telling me the train to Harwich?
C: Sorry—I don't understand.
S: When is the next train Do Harwich?
C: It leaves at three o'clock.
S: What platform is it?
C: It leaves from platform 4.
S: When does he arrive?
C: When does what?
S: When does it arrive?
C: It arrives at half past three.
S: How much is it?
C: It costs two pounds.
S: Thank you. Goodbye.
C: Goodbye.
In computing terms, Station resembles programs in the artificial intelligence field that let naive users ask questions about some topic. One such program is Gus, which books airplane flights from Palo Alto (Bobrow et al. 1977). The idea of Station, though not the programming techniques, is indeed based on Gus.
The first requirement for such programs is a database of relevant information. Station is written in PROLOG, which stores data as relationships between items rather than as lists of items, as in the following small sample of its database:
leave(harwich.three).
ticket(harwich,two)
arrive(harwich,four).
platform (harwich,four).
Thus 'leave(harwich,three).' means that there is a relationship called 'leave' between two items 'harwich' and 'three', i.e. The Harwich train leaves at three o'clock; 'platform(harwich,four).' means there is a relationship 'platform' between the items 'harwich' and 'four', i.e. The Harwich train leaves from platform four, and so on.
The problem is getting from the students' question to the information in the database. The first stage involves discovering what piece of information the questioner wants to know and putting it in the form of the semantic relationship used in the database. This demands a parser like the one illustrated above, but yielding a form of semantic representation as well as the syntactic representation. So the question When is the next train to Harwich? is parsed to get a representation showing which information is missing, 'Next train to Harwich leaves at X', represented in PROLOG as 'leave(harwich, X)'. The question How much is it? requires the information The price of a ticket to Harwich is X, or 'ticket(harwich, X)'. The program searches its database to find something that matches everything but 'X', i.e. 'ticket(harwich, two)'. It now substitutes 'two' for 'X'. Other questions are tackled in the same way. PROLOG can moreover work out relationships thaN are not explicitly stated in the database, by inference. It is thus a different type of computer language from BASIC, which is typically used in CALL programs; a dear account of its use in teaching can be found in Ennals (1983).
To produce the answer containing the right information means using the parser in reverse, i.e. to produce a sentence rather than to analyse it; instead of starting with the sentence When is the next train to Harwich? and ending up with 'leave(harwich, X)', it feeds the answer leave(harwich, three)' into the parser to produce the sentence It leaves at three o'clock.
A practicable small CALL program needs a discourse routine to remind it for instance that it refers to the last train mentioned. It also needs to handle the deviant input that students are likely to use. The solution in Station is similar to Pulman (1984) except that it produces naturalistic prompts rather than descriptions of error. Thus if the student types Could you be telling me the train to Harwich? the program makes nothing at all of the sentence and produces Sorry—I don't understand; if the student types When does he arrive?, the program gets as far as When does and produces When does what? While hardly a sophisticated form of error correction, it can readily be expanded to the limits of the grammar built in to the parser, unlike keyword-matching programs.
In many ways the initial problem of producing CALL exercises that interact flexibly with students and that deal with real information seems to be solved. In terms of communicative teaching the argument has almost gone full circle; the examples of exercises using an information-processing approach resemble those possible with ELIZA; their teaching use with individuals or groups is likely to be similar. The difference is that they can now be developed to higher levels of sophistication and realism. Information- gap games seem particularly transferable to the computer. Dinner Party (Cook 1984b), for example, is a standard communication game in which the students have to devise a menu for a meal by finding out what their guests can eat and what they like to eat. Rather than a class exercise where some students are given the missing information and some are not, they have to find it out by consulting the computer program, which uses virtually the same parser as Station with a different data-base about people's eating habits.
The approach can equally deal with information exchange. Any sort of data may be used, provided they can be organized in the form given above; Musicians (Cook 1984c), for example, allows students to ask questions about jazz history, using basically the same parser but a database with greater powers of inference—e.g. if a musician is great this automatically means he is good. Alternative forms of interaction can also be set up: Musicians replies using a form of hep-talk; Is Miles good? yields He plays a real cool horn, man. In principle many functional role plays could be adapted to this format.
There are at least three dangers in accepting this solution too wholeheartedly. One is that the initial outlay of time and effort in developing the computing techniques is considerable; once done, however, the elements of the parser and data-handling programs found in Station can be used as the core of a whole generation of exercises, rather than being a one-off program. The second danger is believing that the increased depth of computing enables the computer to handle language in any real way; it knows that there is a relationship called 'platform' between 'harwich' and 'four', but it still has no idea what a platform is. Indeed Searle (1984) argues that no computer program does more than simulate language behaviour: all the computer can ever do is juggle with strings of letters in complex fashions, rather than use language. The third danger is that a negative summing up of the computer's contribution could be 'human simulation'. Communicative teaching depends upon people interacting with each other; the programs have substituted a computer for one of the participants involved. Thus, while they certainly allow communicative techniques to be used for self-instruction, hitherto scarcely possible through other means, they at best provide a poor substitute for the fellow student or the living teacher. They do not extend communicative techniques; they replicate them in another medium.
Conclusion
I have tried to show that CALL programs which meet some of the requirements of communicative methodology can in principle be devised; there is no necessity to confine the use of computer programs to more traditional methods. The results achieved so far may not be particularly impressive, except in the possibilities they afford for teacherless communicative teaching. But once such powerful tools as parsers and logical databases are freely available for CALL, who knows what new generation of exercises they may lead to?
Received June 1987
References
Bobrow, D. G., R. M. Kaplan, M. Kay, D. A. Norman, H. Thompson, and T. Winograd. 1977. 'GUS, a frame-driven dialog system.' Artificial Intelligence 8/2:155-73.
Brumfit, C 1984. Communicative Methods in Language Teaching. Cambridge: Cambridge University Press.
Colby, K- M. 1975. Artificial Paranoia: A Computer Simulation of Paranoid Processes. New York: Pergamon.
Cook, V. J. 1984a. Escape From Utopia. Program for a BBC B microcomputer.
Cook, V. J. 1984b. Dinner Party. Program for DEC 10 computer, University of Essex.
Cook, V. J. 1984c. Musicians. Program for DEC 10 computer, University of Essex.
Cook, V. J. 1985a. 'Bridging the gap between computing and language teaching.' ELT Documents 122:13—24.
Cook, V. J. 1985b. Shannon’s Game. Program for BBC B microcomputer.
Cook, V. J. 1985c. Station. Program for DEC 10 computer, University of Essex.
Cook, V. J. 1987. 'Natural language processing as interface between CALL and computing.' Fremdsprachen und Hochschule 20:17-26.
Cook, V. J. and D. Fass. 1986. 'Natural language processing by computer and language teaching.' System.
Cook, V. J. and A. Hamilton. 1984. Chatterbox.Program for BBC B microcomputer. London: The British Council.
Ennals, J. R. 1983. Beginning Micro-Prolog. London: Heinemann.
Hobbit, The. 1983. Program for BBC B microcomputer. Melbourne House.
Imlah, W. G. and J. B. H. du Boulay. 1985. Robust natural language parsing in computer-assisted language instruction.' System 13/2:137-47.
Jones, C. and J. Higgins. 1984. Storyboard. London: Wida.
Krashen, S. and T. Terrell 1983. The Natural Approach. Oxford: Pergamon.
Krutch, J. 1981. Experiments in Artificial Intelligence for Small Computers. Indianapolis: Howard W. Sams.
Littlewood, W. 1981. Communicative Language Teaching. Cambridge: Cambridge University Press.
Markosian, L. Z. and T. A. Ager. 1983. 'Applications of parsing theory to computer assisted instruction.' System 11/1:65-77.
Pullman, S. 1984. 'Limited Domain Systems for Language Teaching.' Paper presented at COLING conference.
Revell, J. 1979. Communicative Techniques for Teaching English. London: Macmillan.
Schank, R- C. and P. G. Childers. 1984. The Cognitive Computer. New York: Addison-Wesley.
Searle, J. 1984. Minds, Brains, and Science. London: BBC.
Starkey, H. 1984. TELEM-NANTES. London: Hodder & Stoughton.
Weizenbaum, J. 1966. 'ELIZA—a computer program for the study of natural language communication between man and machines.' Communications of the Association for Computing Machinery 9:36-45.
Weizenbaum, J. 1976. Computer Power and Human Reason. San Francisco: W. H. Freeman.
Widdowson, H. G. 1978. Teaching Language as Communication. Oxford: Oxford University Press.
Winograd, T. 1983. Language as Cognitive Process: Volume 1 Syntax. New York: Addison-Wesley.
The author
Vivian Cook started as a lecturer in English as a Foreign Language at Ealing Technical College, London, moved to North-East London Polytechnic to run a Polytechnic Language Service, and since 1978 has been a lecturer in Applied Linguistics at Essex University. His current interests are CALL, first and second language acquisition, and the uses of contemporary linguistic theories. He has written on first language acquisition (Young Children and Language, Arnold 1979), on second language learning (Experimental Approaches to Second Language Learning, Pergamon 1986), and on current Chomskyan theory (Chomsky's Universal Grammar: An Introduction, Blackwell 1988), as well as several EFL coursebooks such as Active Intonation (Longman 1968) and People and Places (Pergamon 1980).
