8. Designing and Implementing a Syntactic Parser
Alton SandersWright State
Ruth Sanders
Miami University
Abstract:
Large computer parsers, or language analyzers, can be designed to recognize n7ost correct structures of a natural language and reject n2ost incorrect structures. In order for these parsers to function as effective writing aids for language students, several other kinds of programs must be designed to work with them. A lexicon database, programs to aid the developers, and a word processor for eventual student users are examples. Further commercial tools such as the programming language and editors should be chosen for their ability to enhance tean7work among language and computer specialists. Examples are selected from the Syncheck project, a large parser of German now being implemented.
KEYWORDS: Parsing, Prolog, Definite Clause Grammar, phrase structure grammar, writing aid, Syncheck.
Parsing, or grammatical analysis of sentences, by computer has been the subject of intense and widespread research by computer scientists and linguists for at least the last decade. Many computer parsers of natural language have been designed, most of them intended either as research explorations of various linguistic or computational theories or as adjuncts to large database programs which are queried by users.
Use of the computer's power to accept large formal grammars of language and to test input sentences against these grammars has begun to be explored as a tool for language teaching only fairly recently. While the grammar formalism and its accompanying lexicon are the primary carriers of the subject matter, i.e., the natural language under investigation, an applications parser that is to be useful under real-world conditions must also contain several by-and-large unseen programs that are equally intrinsic to the final program's functioning.
As an example, we describe Syncheck, a computer parser of German we are designing for eventual use by intermediate and advanced college students of German. Implemented in Prolog on an IBM-AT, Syncheck aims at nearly complete
77
coverage of German. It is scheduled for completion in prototype in December 1988, and will be a writing aid for students, who will type their German compositions into the computer and receive on-screen advice as to grammatical correctness, sentence by sentence. No semantic, or meaning, interpretation is included. At the present time there is no error analysis, although a feasibility study is being scheduled for academic 1987-88, and if the results are favorable, error analysis may be included in future revisions of Syncheck.
The program produces a parse tree (sentence diagram) for each sentence it finds to be correct. This aids in development and debugging of the grammar. In the final version, however, parse trees will not be visible to the user. Rather, Syncheck will simply either accept or reject each sentence input to it, based on its grammar of German and its lexicon (approximately 9,000 words). The user will be able to correct any sentence, or choose to let it stand despite Syncheck's judgement that it is ungrammatical. There are two reasons for this: first, a recognition that no syntactic parser can ever be fully reliable, since semantics and world knowledge are also necessary to recognize all grammatical sentences of a language; and second, a principled decision that the student user, not the machine, should be in charge of the composition. After the composition is submitted, the instructor will grade it as usual for content, style, organization and appropriateness, as well as for any grammatical errors missed by Syncheck.
Large Parsers and Small Parsers
There is a distinction between comparatively small parsers, for example those used for a particular set of exercises or those used for an adventure game, and comparatively large parsers, those intended to cover nearly all of a language. Techniques used in the small parsers cannot simply be scaled up and used in a large parser.
Error Analysis
Error Analysis, a relatively straightforward task for a small parser, becomes a substantial problem in a large parser. For example, where a noun phrase consists of an article, an adjective sequence and a noun, it's easy for the parser to identify what went wrong when there is an error. Compare this with a large parser such as Syncheck, which recognizes 23 types of noun phrases that may contain embedded clauses and may be compounded in a number of ways. In the large parser, even when the program is able to identify where the input went wrong, it may not be able to communicate this to the user who does not
78
have as much syntactic knowledge as the program. The user may be mistranslating directly from English and be completely unaware of the complex structure of the sentence.
The Lexicon
In a small parser, and during early stages of development of any parser, it is easy and convenient to make the vocabulary part of the same program as the parser by embedding the lexicon in the grammar. Input is quick, and new words are added ad hoc to test structures as they are described. Such a technique is hopelessly inefficient for a large parser. For example, if the list of nouns consists of "boy," "girl," "dog," and "cat," it is perfectly feasible to list them in the grammar program. Then when parsing the input sentence, the program will do a linear search—that is, it will attempt to match the word found at the noun position with each of the nouns listed. Since there are only four nouns, this will not take long.
When the lexicon grows to 500 nouns, however, such a linear search strategy quickly grows tiresomely slow. An earlier version of our parser that used the linear approach took up to forty minutes a parse. After the vocabulary was taken out of the grammar program and put into a separate data structure called a hash table, it became rare for any parse to take more than a few seconds.
Instead of a linear search, Syncheck performs a hashed search. Each vocabulary word has been stored in the table at a numerical location determined by a formula based on the word, transforming the middle three characters of a word into a three-digit base 26 number. Then, when an input word is to be searched in the lexicon, the program works out what its location in the table should be, and goes directly to that location to begin searching. Even though the "perfect" hash is rare, and the exact location is not always found the first time, such a search is nonetheless considerably more efficient than the linear method, and is absolutely necessary to a parser with a large number of vocabulary words to search.
The Development Process
Before any applications program performs for its users, it must perform for its developers. Development is a process of "try some, throw it away, try again," and the developers must have certain interface programs working so that they can test sentences in much the same way that eventual users will input sentences.
79
For example, Prolog, a relatively new artificial intelligence programming language, is being used to program Syncheck's grammar and the lexicon programs. Like any programming language, Prolog has its own idiosyncrasies. The normal test procedure of Prolog requires that sentences input to it must be in a particular form, known as the programming language syntax, to be tested. To test the sentence "What is your name?", for example, it is necessary to type:
(['What', is, your, name, '?'],X).
Capitalized words, and special characters such as punctuation must be enclosed by single quote marks, and each word is separated from the others by a comma. As the program progresses, sentences grow longer, and typing in test sentences becomes a tedious exercise in itself, especially as any small error in the format will render the sentence unparsable.
Obviously, the developers need a simple editor that will permit typing in a sentence in its normal form, including capital letters, foreign characters, and punctuation; and which will erase typing mistakes with the backspace key. This development editor will almost certainly be thrown away after the program's completion, as it is inadequate for end users.
Other parts of the program work similarly. The grammar, for instance, may be developed initially, as ours was, as a skeleton accounting for a large number of sentence structures, but without detail of morphological agreement. This was simply a way of testing whether the approach we were taking was adequate to handle large structures. Finding that it seemed to be, we began working in detail through each sentence constituent (i.e., noun phrase, adverb sequence, etc.), then combining them into simple sentences. Upon completion, the large superstructure will again be present; but it will have changed considerably as the detail work identified inefficiencies in the original plan.
Specializing
Use of Prolog for the grammar has facilitated the methodology of our team (one linguist, one computer scientist). Syncheck's grammar is being written in a formalism called a Definite Clause Grammar (DCG), which is directly programmable in Prolog. Since a DCG looks a great deal like the standard linguistic formalism, a phrase structure grammar, it may be quickly learned by even a linguist who has little or no familiarity with programming. The linguist may write the grammar and test it directly for accuracy of its logic. Only after they are identified as being reliable descriptions of the language do the grammar clauses need to be fine-tuned for computability and efficiency by the computer
80
scientist. This procedure is a considerable time-saver compared with the procedure of team discussion, specification and programming of every single grammar statement, as is required when other programming languages are used.
As an example, consider this clause describing a compound noun phrase. Morphology has been left off in order to clarify the example, and the problem is an oversimplified one.
compound_np --> np, 'or', np
; np, 'and' np.
This grammar production will run in Prolog, and compound noun phrases with "or" and "and" can be tested on it. However, it is quite inefficient computationally. Consider a sample:
"All the round blue things that I thought I had brought with me from home and the screwdriver"
On the computer, this correct compound noun phrase will first be tested as "np, 'or', np", where it will of course fail; then the program will backtrack and begin checking the noun phrase against the second possibility, "np, 'and', np." But imagine how much computation power and time will have been wasted when, having correctly identified "All the round blue things that I thought I had brought with me from home," it discards its findings upon not encountering the expected "or"; then it must go through that same noun phrase again and re-identify it in order to test it with "and."
In this case, the inefficiency is easily removed by a standard notational technique called "left-factoring," which results in:
compound_np --> np, conjunction, np.
conjunction --> and
;or.
Of course things are seldom this simple. For instance, even in this simplified example the difference in usage between a conjunct (always results in a plural noun phrase) and a disjunct (results in a noun phrase whose number is taken from the last element) must be taken into account.
81
The point here is that a programming language that fosters a method of development in which the linguist is required to be expert only in language (not in computer), while the computer scientist is required to be expert only in computing (not language), is likely to be faster and more satisfactory to both members of the team.
The Programs That Make up Syncheck
There are two kinds of programs that function in Syncheck, aside from the main programs, the grammar and the lexicon. The first category is made up of programs that, though unseen by the user, are for the purpose of aiding the user. The second category consists of programs designed to aid the developers in writing and adding information to the program. Described below are these two kinds of programs.
User Convenience Programs
The Word Processor. As of this writing, Syncheck accepts input from the keyboard one sentence at a time, with a "return" signaling the end of the sentence. Clearly, for a parser to function well with student users, a more extensive user interface must be designed. The intention is for the user to type in the composition, getting advice from Syncheck, and then for the corrected composition to be printed for submission to the instructor. What is needed, then, is an editor or simple word processor that students can learn to use quickly. Because writing and implementing a word processor is a large project which is necessary but not central to our mission, the word processor will probably not go beyond insert and delete, moving of text, word wrap, paragraph formatting and possibly underscoring and italics. More extensive editing functions, such as automatic footnoting, outline capacity and alternate typefaces, will not be included.
The word processor is now being designed. It is being implemented by a research assistant, a Ph.D. candidate in computer science, who will work on this project in the second (1987) and third (1988) years of the project. As the project progresses, the word processor, like the rest of Syncheck, will be tested with intermediate and advanced German students at Miami University as a guide to final revision.
Many students, however, will have their own word processing programs for their own computers. They may wish to compose at home with their own equipment (provided it is IBM-compatible), then bring their disk to the lab to run the draft through Syncheck. Therefore the second editing function of Syncheck will be to accept ASCII files created elsewhere, and to read them in and judge their
82
correctness sentence by sentence. The user should be able to make changes on the spot, or make notes and work on the disk again at home. The program to do this in Syncheck will be implemented by the project's graduate research assistant.
The Scanner. Since the grammar and the lexicon are in two separate programs, they must communicate in order for parsing to occur. The scanner identifies words in the character stream being entered by the user (i.e., picks out word boundaries) and looks up each word in the lexicon to determine 1) whether it is there; 2) if so, what part of speech it is; and 3) what other identifying characteristics (i.e., gender, number, case) are listed with it in the lexicon and must be passed on to the parser. If a word scanned is not found in the lexicon, the message "[word] is not in my vocabulary" appears. In the final version, this message will probably not appear. Most likely the word will simply be marked in some way.
Development Tools
Lexicon Creation and Maintenance Programs. It is not feasible to include in the main program the relatively large lexicon Syncheck will need to reach college compositions. A lexicon of 9,000 words (about the size of a paperback German-English dictionary) seems appropriate for our purposes. The lexicon is a separate database which is consulted by the grammar program during parsing. Entering a lexicon is essential but tedious work, and mistypings are highly significant for the success of the parsing. Therefore it has been necessary to automate, so far as possible, the entry of lexicon items. For instance, adjectives are entered in their root form, and a program automatically generates the strong and weak endings in singular and plural, three genders, and four cases. While inflected adjectives may be predicted from their roots, nouns are less regular. Here the program prompts the developer with yes-no questions as to whether the form typed can be singular/plural, nominative, genitive, dative and accusative cases. Each part of speech declared by the developers (and these do not always coincide exactly with the parts of speech as they appear in traditional grammars) has a particular database format that has been designed to minimize errors in entry.
83
Smaller Tools
We have developed a number of tools to aid in the development process. For example, as the grammar and the lexicon are extended the new parts must be "built" into the total system. We have designed a tool that automatically prompts the developer to go through the steps necessary to input the new data into the larger program. There are batch files for saving our work. There are also prompting programs for saving each day's work from the hard disk of the machine we have worked on to floppy disks, and then in turn uploading the contents of these floppy disks onto other hard disks. (As every programmer knows, it could be fatal to keep only one copy of the canonical program.) On the list for future development is a tool that will make a list of the location in the grammar of any specified non-terminal symbol (such as a particular kind of noun phrase) or terminal symbol (such as a particular lexical item) so that we can more easily keep track of the likely effects throughout the grammar of any change made elsewhere in the grammar.
Other tools are provided by commercial software. Provision must be made in the planning of a large parsing program to purchase licenses for needed software. For example, we are using the database program of Enable to create the lexicon database; we also use Enable's word processor to write running documentation of the program, as well as to write articles such as this one.
As mentioned above, Prolog is the computer language being used to write the grammar and other parts of the parsing program. We are currently using the version marketed by Arity Corp. In addition, we are using the language C for the word processor and some of the other programs. Arity Prolog has interfaces to work directly with C, Pascal and Fortran; using C provides direct access to underlying lower-level functions of the computer.
Thorny but Essential Trivia
Every computer project requires the solution of certain problems that, though knotty to solve, seem trivial in their description, but without which the project cannot succeed. Computer parsing of German provides its share of such thorny trivia. Some examples follow.
1. Sentence Detection
A person who can read German will have no difficulty demarcating each sentence of a prose text. However, the criteria for a sentence must be specified closely for the computer. Consider the following examples:
84
Das Buch ist von J. W. von Goethe.
Ich, z. B., bin müde.
Obviously, the assertion that a sentence ends whenever a period is encountered is insufficient.
2. Punctuation
Sentence punctuation is a syntactic item and must be specified like any other item of grammar or morphology. Unfortunately German punctuation is not identical in use to English punctuation, and students' errors must be caught. An additional difficulty is that the errors will sometimes cause problems in the program's sentence detection (see above).
Example:
Er sagte, "Tisch". [correct]
*Er sagte, "Tisch." [incorrect; will cause the parser to identify the closing quotation mark as part of the next sentence]
3. Capital Letters
All nouns, whether proper or common, must be capitalized in German; in addition, the pronoun "sie" (she/they/you) has a different meaning when capitalized than when not. Further, the word "sie" sometimes appears at the beginning of the sentence and must then be capitalized regardless of its intended meaning. All of these contingencies must be accounted for in the scanner, without loosening the definitions so much that errors in capitalization will be accepted as correct.
4. Foreign Characters
Like several other European languages, German uses characters that are not standard in the Roman alphabet (ä, ö, ü, ß). Students need to be able to input these characters so that they are visible on the screen (known in computerese as What You See Is What You Get) and are printed correctly on paper. In addition, since some students may use a word processor that does not allow them to do this, the parser should recognize the standard substitutions (ae, oe, ue, ss). This means that the scanner should be able to read the word in either spelling. We addressed this problem by storing the words in the lexicon with the standard Roman substitutions. The scanner
85
converts the German characters internally to the standard Roman so a match can proceed. Our editor displays German Characters when the user types a, o, u or s while holding down the Alt key (lower case) or the Control key (upper case Ä, Ö, Ü).
Conclusion
The implementation of a large parser involves the design and integration of not only the language components, but of several other programs as well. Invisible components that the user is unaware of are equally as important to the program's successful functioning as the grammar and the lexicon. Designers of parsers will likely spend as much time and effort on the underlying programs as on the language element itself.
Acknowledgement
Work described in this article is supported by the U.S. Department of Education, International Research and Studies Program, Grant #G008540767, and by Miami and Wright State Universities.
Authors' Biodata
Alton Sanders, Associate Professor of Computer Science Wright State University, earned the Ph.D. in Computer Science at the State University of New York at Stony Brook in 1976.
Ruth Sanders, Associate Professor of German at Miami University, earned the Ph.D. in Germanic Languages and Literatures at the State University of New York at Stony Brook in 1975.
They have worked together for several years on a variety of projects involving parsing of German by computer.
Authors' Addresses
Alton Sanders
Department of Computer Science
Wright State University
Dayton, OH 45435
Ruth Sanders
Department of German, Russian and East Asian Languages
Miami University
Oxford, OH 45056
86
9. An Algorithm For Controlled Integration Of Sound And Text
Harry S. WohlertMartin McCormick
Abstract:
Speech can be integrated into computer-assisted language learning programs (CALL) with Apple II computers and cassette recorders activated by inexpensive cassette control devices (CCD). While this arrangement is increasingly used with great success in foreign language instruction, teachers who want to introduce sound into their computer programs are restricted to programs whose code can be listed because two POKE statements to activate the CCD have to be inserted.
Until now a more serious drawback has been the lack of an algorithm to turn off the cassette recorder automatically to keep screen text and audio in synchronization.
This article offers a program that turns the recorder off automatically and describes how to integrate the audio of a totally computer-controlled cassette recorder with the text of a conventional CALL program. The program code will be in the public domain.
KEYWORDS: audio, computer-assisted language learning, computer-controlled cassette recorder, cassette control device, audio-text synchronization, BASIC, automatic turn off, POKE statement, cassette-control program, VOX, German, Texas Instrument Professional Computer, Apple IIe.
Although microcomputers are enjoying increasing use in foreign language instruction, computer-assisted language learning (CALL) is generally restricted to reading and writing while the other two components of a living language, listening and speaking, are used less frequently. The reasons for the underutilization of the listening and speech capacity of CALL are more than likely a shortage of funds to buy the necessary expensive peripherals or lack of familiarity with the potential and the various technical shortcomings of the Apple IIe, the most widely used computer in foreign language teaching.
Audio and Computer-Assisted Language Learning
At Oklahoma State University, speech and text have been integrated quite effectively for teaching German on a number of Texas Instrument Professional computers which feature excellent voice synthesis (LPC) and acceptable voice recognition systems. However, most computers for practicing German in the language laboratory are Apple IIe's without this advanced technology. Cassette control devices (CCD) were installed on the IIe's to give students the option of taking a dictation (we include dictations on tests but no longer practice them in the classroom), hearing German pronunciation or a line of a dialogue, a translation, or spoken directions rather than making the information available only in written form on the monitor screen. With the CCD it is possible to bring sound—speech or music—to most CALL programs for which the code can be listed.
The CCD is a small relay that can be simply connected with one of its two leads to the I/O (game paddle) port inside the Apple II. The other lead is inserted into the remote jack of any cassette recorder with a microphone hook-up (most cassette recorders have one). The hardware installation takes only about one or two minutes, and the software modification can be completed just as quickly as demonstrated in the following example:
These lines could come from any of the many vocabulary practice programs and should be seen as follows:
1005 the POKE turns on the recorder just before E$(I), an English vocabulary word, is printed for translation onto the
1000............................................................ 1005 POKE -16295,0 1010 VTAB 10 : HTAB 10 : PRINT e$(I) 1015 GET S$ : POKE -16296,1 1020 VTAB 12 : HTAB 10 : INPUT"";A$ 1030............................................................ |
19
screen. The POKE statement is supplied with the CCD and should be inserted wherever the teacher wants the machine to turn on.
1010 will execute the printing. Our students prefer to have the sound when studying the vocabulary for the first time because they can hear the translation, then type the phrase or word to be learned into the computer for checking the spelling, and get the repeated sensory input necessary for overlearning (long memory). The sound can be simply eliminated for review or testing by not inserting a cassette into the recorder. The POKE statements will not affect the program.
1015 The Apple waits for the student to press the space bar. Instructions were given earlier to press any key after hearing the word or phrase twice. After pressing a key the POKE turns off the recorder.
1020 allows students to type the requested response into the computer.
This set-up is inexpensive and can be installed for as little as $80. Although this arrangement will work quite well, it also harbors a more or less serious problem. Since there is no way to predetermine the length of the various utterances, a timing loop cannot be used after which the POKE statement can turn off the recorder. Students have to be instructed instead to press the space bar (GET S$) after hearing the appropriate utterance. The recorder will then turn off (POKE -16296,1). This approach has been used by other language departments, yet most are beset by the continuous problem of a system which gets text and sound out of synchronization; i.e., a student frequently will not press the space bar in time, which permits the cassette player to advance to the next item(s). Consequently, the audio will not match the text on the screen anymore. While an adept student can quickly reestablish synchronization, others will simply give up and refuse to use the audio.
A Computer-Controlled Cassette Program—VOX
A solution to this common dilemma, at least for programs whose code can be listed, was developed by us and has been effectively used for the last six months.
To get the elusive automatic turn-off, we split the audio at the output jack of the cassette recorder with a Y-connector and fed one side into the user's earphone and the other into the cassette input jack located in the back of the Apple II. We then wrote an algorithm that listens for a predetermined pause after which the recorder is turned off. These pauses are inserted between the appropriate utterances on the cassette tape. This system will keep text and audio in synchronization, turn the recorder on and off automatically, and allow the students to concentrate on the learning task without distraction from operating the equipment.
The program (VOX) is a 6502 machine language program (see Figure 1) accessed from Basic through Poke statements. It should not conflict with the memory of any standard Basic program unless that program also contains machine language routines which occupy hex address 300 or decimal address 768.
Cassette Control Program | |
1 Y = 147 | 23 DATA 192,141,88,192,96,1,32 |
2 DIM R(Y) | 24 DATA 4 |
3 DATA 32,88,3,32,49,3,165 | 25 FOR X = 0 TO Y |
4 DATA 3,205,145,3,16,6,76 | 26 READ R(X) |
5 DATA 3,3,32,88,3,32,49 | 27 NEXT X |
6 DATA 3,165,3,205,145,3,16 | 28 FOR X = 0 TO Y |
7 DATA 246,174,146,3,32,49,3 | 29 POKE X + 768,R(X) |
8 DATA 165,3,205,145,3,16,233 | 30 NEXT X |
9 DATA 202,208,243,141,88,192,96 | 31 REM CALL 768 RUNS OUT THE LEADER |
10 DATA 138,72,173,96,192,41,128 | 32 REM CALL 784 IS USED AFTER THE LEADER IS OUT AND THE PROGRAM IS BEING EXECUTED |
11 DATA 133,2,169,0,133,3,162 | 34 REM 913 THRESHOLD ADDRESS. 914 IS THE DELAY OFR THE SILENCE DETECTOR. |
12 DATA 255,169,7,32,168,252,173 | 35 REM 915 IS THE DELAY FOR THE STARTUP PAUSE TO ALLOW TAPE PLAYER TO COME UP TO SPEED |
13 DATA 96,192,41,128,197,2,240 | 100 FOR X = 768 TO 915 |
14 DATA 4,133,2,230,3,202,208 | 110 0 = O + PEEK (X) |
15 DATA 235,104,170,96,141,89,192 | 120 NEXT X |
16 DATA 174,147,3,169,255,32,168 | 130 P = 16226 |
17 DATA 252,202,208,248,96,173,96 | 140 IF 0 = P THEN PRINT "EVERYTHING IS PERFECT |
18 DATA 192,141,89,192,133,2,44 | 150 IF 0 >< P THEN PRINT "THERE IS A PROBLEM. 0 = ';0;" IT SHOULD = ";P |
19 DATA 0,192,48,22,169,7,32 | 160 D$ = CHR$(4) |
20 DATA 168,252,173,96,192,41,128 | 170 PRINT D$; "RUN MENU" |
21 DATA 197,2,240,237,133,2,174 | |
22 DATA 48,192,76,111,3,141,16 | |
Figure 1 | |
How to Install VOX
Type in the VOX program as listed in Figure 1 and then type "run". The lines starting with 100 contain a checking routine which will test for typing errors in the data statements. If the message indicates that there is a problem, then check the data statements. After the program gives the message that all is well, it may be tested and used.
Put a cassette into the recorder and depress the Play button. If the cassette control device (CCD) is plugged into the recorder, the machine should not start. On Apple IIe's, the game paddle annunciators or switches do sometimes
20
come on when the system is powered up, so do not be surprised if the motor starts.
Now type "CALL 871". If the motor is not already running, it should start now. As soon as there is sound on the tape, it should be audible in the computer's speaker as a series of squawks and clicks. Adjust the volume control on the tape player until the listening level is comfortable in the earphones and the Apple's speaker is silent between tape sounds. If the volume level is too high, a high level of noise will come from the Apple's speaker even between words when it should be quiet. Once the level is set, hit any key on the keyboard and the motor should stop. If it does not stop, there is a problem. Check all connections to the remote switch for correct installation. If the motor does stop, then everything is ready.
Type "CALL 784". The motor on the recorder should restart. If there is sound present, it should keep running until there is a period of silence longer than approximately 1.75 seconds. At this point, the machine will stop, and the system will be back in Basic again.
Now type "CALL 871". It will restart the machine and rewind the tape to the very beginning. Press any key to turn the system off and then press the playback key on the recorder. The motor should be off.
Type "CALL 768". The motor should start, and the machine will run until the leader has run out and the first sounds are encountered. The tape will continue to run until the first silence. If everything worked as described so far, then a good copy of the program has been made, and the system has been properly connected. Before doing anything else, save the program onto the disk. To make the silence detector operate sooner than 2 seconds, poke 914 with a number smaller than 32. The range is approximately 1/20 of a second for poking 914,1 to about 15 seconds for poking 914,255. Address 915 contains another timer which controls the amount of time that the computer will spend waiting for the cassette player's motor to come up to speed and its amplifier to produce sound. It is currently set for about 1 3/4 of a second (line 155, POKE 914,24).
Change its time the same way the silence detector was changed. This basic program was designed to be part of a larger basic program of your own design. Place it so that it executes first. You might put a line containing a clear statement between it and your program to reset all variables to 0 since they are not needed after the machine language creation program runs once.
How to Integrate VOX into a Basic Program
The three CALL statements - CALL 768, CALL 784, CALL 871 - must be inserted into your BASIC program in a manner similar to the one described below. Do not use the POKE statements supplied with the CCD; they are not needed!
Remember that the Apple will listen to some sound after the leader of the cassette has run out. It will turn off after the first period of silence is encountered. Therefore, record a few words such as are you ready? onto the tape, count silently one thousand and one, and say the utterance the program user is supposed to hear, count one thousand and one, say the next utterance, and so on.
100 GOSUB 7000 | 7020 VTAB 20: HTAB 7: PRINT"Press any key to continue!" |
110 CALL 768 :REM runs out the leader of the cassette | 7030 CALL 871: REM allows rewind of tape without unplugging the CCD. Press any key to return to BASIC. |
3000 CALL 784 :REM turns motor on until silent period of about 1.75 seconds occurs. | 7040 VTAB 8: HTAB 5: PRINT"Press SPACE BAR immediately!" |
7000 VTAB 8: HTAB 5: PRINT"Rewind cassette and press PLAY." | 7050 VTAB 11: HTAB 6: PRINT"Now wait for instructions..." |
7010 VTAB 14: HTAB 18: PRINT"then" | 7060 RETURN |
Figure 2 | |
Hardware for the Cassette Control Program
The following items must be purchased for every computer that is supposed to work with the audio cassettes:
1. A cassette recorder with a remote microphone input jack. A simple $20 to $30 cassette recorder should work very well.
2. A mini stereo headphone, the Radio Shack headphone (Cat. No. 33-1000A) for $4.90 has worked very well. However, the sound will come out of only one side which students find very annoying. Buy stereo/mono headphones (Radio Shack, Cat. No. 33-196C, $9.95 on sale) or the following stereo to mono adapter or any other equivalent adapters to fix this problem.
3. A headphone adapter, Radio Shack (stereo to mono, Cat. No. 274-368) for $1.19.
4. A Y-adapter, Radio Shack (Cat. No. 42-2463) for $4.49 or any similar one.
5. An extension cord with miniature to miniature phone plug (both ends are male). Radio Shack has a 6 ft cord (Cat. No. 42-2420) for $2.29 available.
6. A cassette control device, Hartley Software or most computer stores sell it for about $70.
We used the Radio Shack parts because of the convenient location of the store. Equivalent parts that are already on hand or available elsewhere are equally acceptable.
To use the Apple IIe for automatic control of the cassette recorder, connect the hardware listed above as follows:
1. Open the Apple IIe and connect one end of the cassette control device to the game paddle port (right upper corner viewed from the front). The wire coming from the connector should be pointed toward the back of the computer. Close the Apple II and simply connect the other lead to the remote jack of the cassette recorder.
21
2. Plug Y-adapter into the headphone or monitor jack of the cassette recorder.
3. Connect one end of the headphone adapter (stereo to mono) to the Y-adapter and the other end to the headphone.
4. Plug one end of the extension cord into the unconnected lead of the Y-adapter and the other end into the cassette input jack of the Apple II (lower left hand corner if viewed from the front).
5. Turn the volume control of the recorder to the middle or use the calibration routine described above. If it is set too high or too low, the cassette will not stop automatically.
Please, note that the last two lines of the VOX will run the menu automatically. Change the word MENU to the name of the program that you want to run next. Do not forget to run the VOX program before the main program is started. For that reason it is also a good idea to put the statements in line 160 and 170 into your Hello program (change MENU to VOX).
Conclusion
This solution to the audio-text synchronization problem should enhance the use of a simple cassette recorder with various CALL programs. While the Tandberg random access cassette recorder or the Instavox record/playback unit are technologically more advanced, their prices are also more than 15 to 30 times higher. At present, a simple cassette recorder provides the most cost-effective way to integrate speech into computer-assisted learning, whenever it is considered useful and appropriate.
Author's Address
Harry S. Wohlert or
Martin McCormick
Oklahoma State University
Department of Foreign Languages and Literatures
MS 229
Stillwater, Oklahoma 74078
10. Template System For Second Language Aural Comprehension
Donna MydlarskiDana Paramskas
Abstract:
With the introduction of the PROMPT template materials into the French, Italian, and Spanish classes at the Universities of Calgary and Guelph, Canada, it became evident that a system to help language students improve their listening skills was much needed. In response to this need, a template called DICTATE was developed to allow teachers to use the dictation format to practice auditory discrimination, aural comprehension, and orthography in the most efficient and effective way possible.
KEYWORDS: templates, authoring systems, CALL, reading comprehension, listening comprehension, error correction.
Once upon a time, there were mainframes and man was supposed to conform to their needs, their requirements, and their exotic rites. Teachers took one look at the pedagogical implications and, for the most part, fled as fast and as far away as they could. It took them almost twenty years to return. Meanwhile, some interesting things had happened. The big machines shrank in size, perhaps under the inspiration of that Alice who, by shrinking, discovered Wonderland. First they shrank down to mini size, and finally down to micro. In this guise, they were much less frightening. A room full of machinery is the stuff of science fiction, or even horror films; a small TV-like screen, full of things called bits and bytes and, occasionally, bugs, is rather benign and easy to control.
The first CAI programs took the form of programmed learning, partly because of the limitations of the mainframes, but also because most programs were designed for the sciences, where logic reigns, answers are true or false, and every learner proceeds according to a set sequence. Needless to say, this format horrified people in the humanities. When the machines became tamer, they also acquired software which was more and more user-friendly in contrast to mainframe operations. An ordinary person could learn to program using simplified languages like BASIC. And for those not interested in programming, there were even simpler systems, called authoring systems, which allowed beginners to create CAI lessons—a bit like the old Assimil language learning method, English Without Tears.
However, all was not for the best in the best of possible worlds. Simple for computers does not mean exactly the same thing as in normal language. To use authoring systems efficiently, one still had to put in a good bit of time, work within the limits resulting from the simplicity of the programming and, just like learning a second language, keep practicing so as not to lose the skills. Some teachers, fired by futuristic dreams, plunged right in and created CAI materials which were often creative and useful. But it was evident that the majority of teachers, and not only in languages, remained aloof—and for very valid reasons: timetables already overcrowded, professional responsibilities which demanded whatever energy that was left after classes.
Among those resisting the impulse to transform themselves into programmers, or authoring-systems experts, some were content to go in search of ready-made programs and use them as one uses any commercial materials: sorting out the offerings, trying to find something which would correspond to their particular learners' needs. It wasn't ideal, but it worked—more or less, IF you put in the time necessary to shop around, and IF you did not become discouraged by the numerous pedagogically unsound, even though colors flashed, pixels bounced, and electronic music resounded.
There was another group of teachers, not happy with commercial programs, not ready to spend much time learning a new skill, but who saw a definite place for the computer in language learning. This is the target group for whom we began to design a specialized authoring system which we call a series of templates. Authoring systems are generally all-purpose programs, permitting CAI in topics ranging from arithmetic to zoology. The width of the possibilities limits the depth or the complexity with which a specific area can be dealt. The template, much humbler, usually targets one subject
8
only, and within that subject, only one format at a time. But being so specialized, it can dedicate itself to producing something excellent—very simple for the teacher to use, but very sophisticated in terms of programming.
Our first template, PROMPT, is designed for exercises in reading comprehension in two formats: multiple choice or fill in the blanks (Mydlarski and Paramskas, 1984). The program picks up spelling errors, morphological errors, and can give the exact comment to students that the teachers/authors would give if they had corrected the student's work in the traditional manner. But where it would have been necessary to write the same comment on the same error endless number of times, the teacher need do it only once, and the program will do the repetitive work, adding the name of the student doing the exercise, if desired.
We must insist on the fact that the aim of a template is to give the teacher a good tool. The template in no way guarantees the quality of the pedagogical content. If the users are poor teachers, they will produce poor courseware, with or without a template. PROMPT and similar templates offer model lessons which users can imitate, but in the end, responsibility for quality lies precisely where it should: with the teacher, not the machinery.
Template-type programs are now appearing on the market which combine ready-made lessons and templates permitting the user to modify the lessons or to write supplementary lessons (Jones, STORYBOOK and CLOZE). In the future, teachers searching for good courseware will be able to consult a whole bank or library of templates, find the format which corresponds exactly to their needs, and be able to write a lesson in a few minutes. Obviously, these few minutes do not include preparation time: the quality of any CAI materials is totally dependent on the time and effort applied to preparation, and this is true of any learning material, be it in print, on film, or on a computer. The advantage of the computer, is that it allows the teacher to greatly shorten correction time without taking away from individual attention for each student.
DICTATE
When the PROMPT materials were implemented in our French, Italian and Spanish classes, it became evident that a system to help language students improve their listening skills was needed. Although literature in second language acquisition has recognized for a number of years the importance of providing comprehensible input (Postovsky, Krashen, Terrell), the fact remains that students are generally expected to acquire listening skills on their own through a kind of osmosis. The need exists for individual, supervised practice so as to build up solid skills. However, most course syllabuses do not allow time for this tutorial approach. Computer assisted instruction, used as an out-of-class activity, may well provide a solution.
Listening skills may be developed through a variety of approaches: aural/oral, aural/action, aural/written. Since CAI is at present generally limited to written input, only the third approach can make effective use of the computer at this time. Again, for this approach, numerous formats are available to check/test comprehension of aural stimuli: multiple choice, cloze or fill-in-the-blanks, sentence completion, paraphrasing, to mention only a few. One of the most venerable formats, and still highly thought of in spite of the numerous revolutions in language teaching, is that of dictation, which
9
combines several skills: auditory discrimination, aural comprehension, and orthography.
The template called DICTATE was developed to allow teachers to use this format in the most efficient and effective way possible. It is a thoroughly user-friendly system which has several advantages over the pencil and paper dictation exercise. It was intended that DICTATE should offer more learning opportunities than available in the traditional dictation, if it were to exploit CAI to the fullest.
Traditionally, dictation takes place in the classroom where the teacher reads a paragraph aloud and the student writes it down. The teacher may read the text more than once but this may not be enough for students who have difficulty understanding. Moreover, language teachers tend to overarticulate and unconsciously deform the aural patterns of the language. Furthermore, these dictations are usually quizzes and are written under stress. With regard to feedback, teachers vary in the amount of correction they give. Students must wait at best for twenty-four hours (sometimes several days) before the dictation is returned.
DICTATE has none of these drawbacks. There is minimal stress, since the purpose is learning rather than testing, and the privacy provided by the computer assures a non-judgmental learning environment. The student is presented with a variety of speech, ranging from the instructor's familiar voice, through pre-packaged tapes and authentic speech obtained from media such as radio or television. Feedback is immediate and the marking of the dictation is very detailed. In addition, several strategies are used to heighten motivation by giving the student a sense of control. These will be discussed elsewhere in the paper.
By using an intuitive approach based on our experience in second language teaching, we developed a basic design which was circulated to colleagues for their reaction. We then surveyed the research literature to ascertain whether current findings confirmed our views on what constituted good pedagogy. A number of articles proved helpful in refining our design. James Pusack's classic article, Answer-Processing and Error Correction in Foreign Language CAI (1983), reinforced our decision to combine error anticipation and pattern mark-up: that is, to provide both verbal and graphic analysis of the student's answer. James Hendrickson's The Treatment of Error in Written Work (1980) clarified the distinction between direct and indirect correction treatment and encouraged us to use a discovery approach to correction as often as possible. One adaptation inspired by Hendrickson was to give the control of the program to the student. Instead of the teacher (or the system) deciding which error would be treated directly (i.e. with a specific help message) or indirectly (by indicating either the presence or the location of an error), DICTATE highlights all errors—using reverse video—and lets students decide whether they need further help. Finally, David Wyatt's paper, Computer-Assisted Teaching and Testing of Reading and Listening (9184) gave a good description of the state of the art. DICTATE would fall under Wyatt's heading of collaborative computer programs, where the initiative is turned over to the student (or a group of students).
Like PROMPT, DICTATE consists of two dimensions: 1) a program of prompts directed to teachers who merely need to type in their material in natural language and 2) an interpreter program which uses the material entered and displays it for student use. All templates are designed for the IBM PC and incorporate a routine for producing accents, developed by our universities (in collaboration with Concordia University in Montreal).
DICTATE AUTHORING SYSTEM
The authoring system operates much like PROMPT with regard to text and dictionary entry. Authors choose from among the six target languages available: English, French, German, Italian, Latin and Spanish. They may choose an existing passage or create their own. As source material, instructors may select any audio tape or any written text which they will then record on tape. Once the material is ready, it is entered as on a typewriter. Instructors have only to provide a glossary and the anticipated errors, with a comment attached to each error.
The anticipated error program is unique to DICTATE. It enables teachers to provide help messages, if desired, for any predictable wrong answers that they might identify. However, since the same word could conceivably occur several times in the dictation passage, a routine had to be developed to determine whether the comment refers to:
- all instances in which the word occurs
- to some instances (and if so, to which ones)
- to no other occurrences.
By positioning the cursor, authors can indicate for which occurrences of the same word their special comment applies. It was felt that common semantic and syntactical errors could be handled this way, based on the expertise accumulated over the years by experienced language teachers. This would complement the more mechanical check performed by the computer. If teachers/authors choose not to supply any anticipated errors with appropriate comments, the program will automatically proceed to check the spelling. More details on answer processing will be given in the discussion of the student system.
Other features of the authoring system include the capability to try out a lesson just created, to rename an exercise and to delete an exercise. Any or all parts of an exercise may be added to, deleted or changed in seconds, either at the time of creation or at some future time.
10
THE STUDENT SYSTEM
In these exercises, the dictation will be supplied by an audio device, probably a cassette recorder. The student may have listened to the tape prior to coming to the computer. In the student system, a list of exercises is first presented to the students. The students have the option of viewing a series of information (help) pages. These include information on editing keys, foreign accents and the scoring system. The students are told to listen to the first sentence on the tape and to type it in a box on the screen, called the work area. They can edit the sentence and, when satisfied, press the F1 key to have the sentence checked. The computer highlights (using reverse video) all errors which the student may then correct. Otherwise, help in the form of a clue, a letter or a word may be requested. Once the sentence is correct, it is moved to the top of the screen and the work area is cleared to enable the student to begin the next sentence.
To increase motivation, a score is kept. Points are lost for requesting a clue, a letter, a word or a check (the first check, however, is free). It was intended to encourage students to get the sentence right on their own, or with as little help as possible.
There are many useful commands available to students while doing the exercise. It should be noted that F7 (dictionary) recognizes approximate spellings, provided the first four letters are correct. This was deemed important given the aural nature of the exercise. Figure 1 explains the functions of the various commands.
It was felt that the correction of one sentence at a time, although different from the procedure commonly used in pencil and paper dictation, offered several advantages. A lengthy dictation would involve a lot of typing and could become boring or discouraging, particularly if the whole screen is lit up with errors (the electronic equivalent of the bleeding page). Moreover, it was hoped that a student might learn from a mistake in one sentence and avoid making the same error later on, if the word were to recur. It was also felt that, because a student cannot advance in the exercise until the current sentence is correct, a series of small successes would—unlike the red ink effect—maintain the user's self-image and provide motivation to continue. Finally, this approach requires less coding and speeds up the execution of the computer program.
As mentioned above, DICTATE uses a combination of pattern mark-up and error anticipation. The mark-up pin-points the location of the problem by highlighting incorrect characters. Dashes are inserted for each missing letter. The system adjusts for non-significant punctuation and capitalization. Unwanted spaces are ignored. If further analysis is desired, students request a clue by pressing F2. Clues are verbal explanations provided by either the author or the system. In the case of the former, the clue is the comment that the instructor supplied for the anticipated error. The majority of the clues, however, are provided by the machine; some examples are:
- Sentences begin with capitals.
- Proper nouns need capitals.
- Extra letter[s].
- Inverted letters.
- Extra word.
- Accent is missing.
- Final punctuation is missing.
- Right letter, wrong accent.
- Double consonant.
The student system has other features which give the users a sense of control and help to maintain their motivation. For example, students are able to correct their errors in any order (within the sentence). The complaint or gripe key enables the student to log a complaint, report any problems or make suggestions. DICTATE also provides reasonableness checks. If sixty percent of the sentence is incorrect, the computer will not mark the sentence. This would indicate that the student may have chosen an exercise far beyond his/her ability or that s/he may be listening to the wrong tape.
Figure 2 shows one screen of an exercise as it is displayed to the student along with some notes of the interaction that might occur.
CONCLUSION
DICTATE was a more ambitious project than we have originally realized. As the plan was refined, it became more and more complex. In particular, the mark-up of the incorrect sentence and the error handling are much more explicit than in the original design. Similarly, the anticipated error program in the authoring system is highly sophisticated. To date, evaluation has been of a formative nature. Care was taken to involve faculty members at an early stage of the development. Peer review of the materials provided the developers with constructive criticism while building on the stakeholder approach: that is, that teachers/authors must be an active participant in the enterprise from the beginning, if CAI is to be successful, as numerous studies have shown (Brebner, Johnson and Mydlarski, 1984; Kearsley and Hillelsohn, 1982).
The next step will involve pilot testing of the teacher-created exercises with students. In the final analysis, it is the teacher who determines the success or failure of a particular CALL (computer assisted language learning) application. Teachers will have the responsibility of integrating DICTATE (and other materials such as those created with PROMPT) into the total learning experience. They must address the basic questions: who will use the DICTATE exercise? how will they be used? how will their use affect the existing language program? Availing themselves of the computer as an out-of-class ally, the teacher must decide how classroom time might be made more productive.
Finally, future enhancements of the aural comprehension template system will include:
- provision of written documentation in the form of a user's guide
11
- consideration of improvements to the student/machine interface; for example, the provision of rest periods. At present, if students quit the exercise before the end for any reason, they have to start all over again. One possibility is to have the system remember where the student left off.
- completion of the LISTEN template, a format using an audio text accompanied by a series of multiple choice questions (written) augmented by a computer assisted tutorial approach.
ENDNOTE
The project reported in this paper was supported by the Department of the Secretary of State, Canada, whose assistance is gratefully acknowledged.
REFERENCES
Brebner, A., Johnson, K. and Mydlarski, D. "CAI and second language learning—an evaluation of programs for drill and practice in written French." Computers and Education 1984, No. 8, 471-474.
Hendrickson, James M. "The treatment of error in written work." The Modern Language Journal. Summer 1980, 216-221.
Kearsley, Greg P. and Hillelsohn, Michael J. "Human factors considerations for computer-based training." Journal of Computer-Based Instruction, May 1982, 74-84.
Mydlarski, Donna and Paramskas, Dana. "PROMPT; a template system for second language reading comprehension." CALICO Journal, June 1984, 3-7.
Pusack, James P. "Answer-processing and error correction in foreign language CAI." System, 1983, No. 11, 53-407.
Authors' Addresses
Donna Mydlarski
Associate Professor
Dept. of French, Italian, and Spanish
The University of Calgary
2500 University Drive
Calgary, Alberta
Canada T2N 1N4
Dana Paramskas
Associate Professor of French Studies
Department of Languages
University of Guelph
Guelph, Ontario, Canada N1G 2W1
