VOCAL: A CASE STUDY INTHE METHODOLOGY OF THE DESIGN OF

AUTHORING LANGUAGES FORCOMPUTER-ASSISTED INSTRUCTION

by

ROBERT SMITH

Department of Computer ScienceRutgers University

New Brunswick, NJ.

THE HISTORY of the use of computers is a history of the development oflanguages for describing information to computers. The commonest andmost successful such languages have been the algorithmic or programminglanguages; most work on language theory in computer science concernsthese languages. However, a wide variety of other kinds of languages havebeen developed as well. These include languages for describing tables, setsof data, manuscripts to be processed, and so on. All of these languages aresupported by special interpreters and compilers on the host machine. Manyof the tasks undertaken by these languages are poorly understood, forexample, text-processing and computer-assisted instruction.

Considerable effort has been put into developing and using special pur­pose languages foY computer-assisted instruction. Such languages areusually called authoring languages (AL for short). The lack of a good AL,especially a portable AL that would allow instructional material to betransported between host machines of different manufacture and configu­ration is often seen to be a serious problem blocking the spread of CAL

The research reported iR this article was partially supported by National Science Founda­tion Grant EPP-74-15016-AOI to Stanford Uniyersity. The VOCAL language was developedover a several month period by a good group of people working closely together. I wouldespecially like to thank John Prebus, Mike Hinckley, Bob Laddaga, and Bill Sanders for theirassistance. Others who later contributed include Mark Davis, Teri Pettit, Arvin Levine, LarryMarkosian, Ron Roberts, Scott Daniels, and Jos Marlowe.

Since this article concerns ideas about the development l:f software for computer-assistedinstruction, it is perhaps appropriate to give special thanks to John Prebus. His programmingtalents and good sense about software engineering were responsible "behind the scenes" formuch that has been good in Stanford's CAl research. The programming of VOCAL was John'slast contribution to this effort.

Bob Laddaga and Lee Blaine read the draft of this article and made many useful comments.Also, we thank Patrick Suppes for the conception of the importance of the use of audio in

human learning and man/machine interaction.

791

792 SMITH

See for example the recent survey by Chambers and Sprecher (1980),where the need for a general purpose authoring language is stronglyemphasized.

There are good economic reasons for the. importance of authoringlanguages. It is now clear that the development of a good CAl curriculumis an expensive and time-consuming task. Finding a convenient way forexpressing such curricula - and reducing authoring and upgrading timeand effort-is important.

Also, it has been argued many times that the expense of producing CAlmaterials can only be justified if they can be used at many locations. Variousstrategies for transporting CAL systems, including networking, micro­processors, and portable languages have been proposed.

Perhaps the commonest proposal is to develop a standardized authoringlanguage which can be implemented on a variety of systems and used stan­dardly for CAl development. Such a language would make transportingCAL material easier, it is argued, and would thus encourage development.

This article takes the view that the task of designing such a generalpurpose authoring language is a methodological mistake. We simply do notknow enough about what and how we want to teach to make such generalsystems workable. Instead, the article argues for a methodology of con­structing special purpose authoring languages when specific conceptions of the-instructional process have developed. We feel that this approach will yieldbetter CAl, and we also believe that it is compatible with the need totransport instructional systems, provided the right software tools andalgorithmic programming languages are developed to permit the develop­ment and export of special purpose CAl authoring languages.

We begin with a general theory of computer languages, and proceed toshow how CAl authoring languages relate to this theory. The well-knownTUTOR language (see Sherwood, 1974) is then used as an example of thebest general purpose CAl authoring language. We note the deficiencies ofbuilding such general purpose ALs and then propose a methodology fordeveloping special purpose ALs. The methodology proposed evolved overthe past decade at the Institute for Mathematical Studies in the SocialSciences (IMSSS) at Stanford University.

The body of the article is a description of the last of the authoringlanguages developed at IMSSS, the VOCAL language. We describe thedevelopment of this language as an example of the methodology we areadvocating.

1. COMPUTER LANGUAGES AND CAl AUTHORING LANGUAGES

Our underlying position is that computer languages should have both aformal definition and a meta-theoretic interpretation. The formal definitionof the language includes the rules of syntax and the rules of the "abstract

VOCAL 793

machine" that interprets the language; the meta-theoretic interpretation of thelanguage cousists of the things that one is trying to describe with thelanguage. The best situation is when one has a mathematically rigorousproof that the formal definition captures in some "reasonable" way theobjects, statements, or processes that are intended by the meta-theoreticinterpretation.1

For example, the COBOL language is designed to perform the oper­ations needed on tables of information in the form that business dataprocessing often requires; these tasks related to data processing form themeta-theoretic interpretation of the language. The fact that the language"reasonably" represents these tasks is one reason for its success. COBOL'slimitations are also well known.

For use in CAl, the formal definition of an AL should permit the reason­able expression of instructional material. The meta-theoretic interpretationof a CAl language should allow expression of at least the following kindsof things:

1. Presentation: What is presented to the student, and how it is presented,should be capable of being stated in the authoring language.

2. Response evaluation: How to evaluate student responses, whether they are"correct", "incorrect", or require special action or response by the instruc~

tional system, must be stateable in the AL.

3. Branching: How material is to be selected next-new material, remedialmaterial, etc.-must be specifiable in the authoring language.

Most CAl systems, and the ALs in which they are written, have ways ofspecifying the above.

This division is misleading for two reasons. First, it is easy to specifyauthoring languages that appear to do these things, but do them only incertain highly restricted ways; and second, each of these conceptual opera­tions can involve, in actual teaching, arbitrarily much knowledge and com­putation on the part of the teacher in a way that completely exceeds whatwe know how to program or even describe with precision.

1.1 An Example from TUTOR

To motivate our methodological discussion, we shall consider a sampleTUTOR program in some detail. TUTOR, the language associated withthe PLATO project, is perhaps the best known AL and we select it becausewe think it is the best extant attempt to develop a general-purpose AL.

Consider the instructional "program" given in Figure 1 written in anALGOL-like language. It presents a question and evaluates the student's

lThe difficulty in making such an argument rests, in part, on the lack of a notion of "rea­sonable"; indeed, by not constraining the notion of "reasonable", it is trivially true that manycomputer languates are universal in the Turing~machine sense including languages that werenot actually intended to be universal.

794 SMITH

response. A count of the number of correct or incorrect answers is keptexplicitly by the program and is used as the basis of a branching decision.

One can of course code lessons in traditional programming languages.An AL can, however, allow greater ease of expression and can provide easysolutions to instructional problems that commonly develop if the process­ing is stated in a general algorithmic language. In the program in Figure I,notice that the student might respond "George Washington" instead of"Washington" and the response would be counted as incorrect. Also, if thestudent answers "Jefferson" it might be appropriate to clear up an appar­ent confusion of properties of presidents.

PRESENT:WRITE ("Who lived at Mount Vernon?");

EVALUATE:RESPONSE <-input response from student;IF ANSWER = "Washington" THEN

CORRECT <-CORRECT + IELSE

WRONG <-WRONG + I;

BRANCH:IF CORRECT> 10 THEN GOTO next lesson;

FIGURE I. Sample "CAl Exercise".

Consider now the TUTOR rewrite given in Figure 2. It uses some of thefacilities of the TUTOR language to solve the instructional deficiencies ofthe code in Figure 1; it also has a certain syntactic economy. In Figure 3wegIve an algorithmic version of the TUTOR program. Notice that a fullfleshing out of this algorithm would produce a fairly lengthy program.

writearrowansweratwritewrongatwritearrowatwriteanswer

Who lived at Mount Vemon?1015(George,G) Washington1120Great!Jefferson1112No, he lived at Monticello.17151512In what state is it located?(Va, Virginia)

FIGURE 2. Sample TUTOR Code.

VOCAL

WRITE ("Who lived at Mount Vernon?");

RESPONSE input from student(putting arrow prompt at screen location 1015);

IF RESPONSE = "Washington" ORRESPONSE = "George Washington" ORRESPONSE = "G Washington" THEN

WRITE ("Great", at screen location 1120)count answer as correct;

ELSEIF RESPONSE = "Jefferson" THEN

WRITE ("No, he lived at Monticello");count answer as wrong;

WRITE ("In what state is it located?");

RESPONSE +-input from student(arrow prompt at 1715);

IF RESPONSE = "Va" OR RESPONSE = "Virginia" THENdefault correct printout;count answer as correct;

ELSEdefault incorrect printout;count answer as wrong;

FIGURE 3. Algorithmic Version of Figure 2.

795

The TUTOR language has extensive features for ')udging" studentresponses; the curriculum author can state quite economically a variety oftests that the system can make on a response. For example, the TUTORcode in Figure 2 includes a pattern-specification that allows the considera­tion of several possible responses ("Washington", "G Washington", etc.). Inaddition, anticipated wrong answers can receive special attention.

There are several characteristics of TUTOR coding that are commonwith most ALs (and with many specialized computer languages). Theseinclude:

I. Level of abstraction: The primitives of the TUTOR code in this exampleare slightly more abstract than the corresponding parts of the algorithmicversion. For example, such matters as keeping count of correct and incorrectresponses are hidden inside the TUTOR interpreter and thus the curriculumauthor does not have to be concerned with this aspect of the coding.

2. Compression of syntax: Many syntactic details are omitted from the TUTORversion. For example, no quotes are needed around strings, implicit "ORs"

796 SMITH

are suggested by the pattern language, and so on. Compression of syntax is acommon feature of specialized languages, making authors do less typing.Sometimes the omission of such details creates problems by requiring theauthor to learn many special cases, and this can become a burden. The TUTORlang'uage has too many primitives and some awkward special-case rules as aresult of the compression of syntax.

3. Elimination of variables: Storage for information such as the response andthe count of number of items correct or incorrect does not have to be men­tioned by the author but instead is kept by the system. This is excellent as longas the author does not need to access these things. However, declaring andusing data in many ALs, including TUTOR,is less convenient than in tradi­tional programming languages.

4. Elimination of structure: The control structure of the TUTOR code is actuallysomewhat obfuscated by the rules of the TUTOR language. For example, theconditional structure of the operations may not be apparent from the TUTORcode. Whether or not this suppression of control structure is an advantagecan vary from one situation to another. Sometimes it is extremely confusing inTUTOR and some of the control-structure rules, particularly concerning the"satisfaction of an arrow", can be annoying to the author.

Special-purpose computer languages, and ALs in particular, have incommon that certain features of the languages may be "buried" inside theinterpreter. This may in many cases result in higher-level primitives and incompression of seemingly unneeded syntax; it may also result in the elimi­nation from explicit mention of things that are quite important for theauthor to notice and that require fairly sophisticated and detailed knowl­edge of the interpreter to rationalize. This can lead to forcing the authorinto awkward coding in order to capture what he wants to program and theresulting lessons can be oblique and unreadable as a result.

The correct design criterion with respect to the suppression of detailappears to be: bury all "unnecessary" detail since the user does not want tosee it, but don't bury any "necessary" detail. An equivalent formulation ofthis is that the meta-theoretic interpretation of the language should be clearto the user without his having to understand any of the details of implemen­tation.

The intended interpretation of TUTOR - the kind of instruction thatone can reasonably describe with the language - appears to be the following:

1. Presentation of material using graphics involving simply geometric objects(such as lines, circles) and specially designed character fonts.

2. Response evaluation using reasonably extensive pattern matching driven byresponse patterns and tables of words and pattern phrases. Both correct andanticipated incorrect forms can drive the evaluation. Teacher response tostudent answers is data driven from the results of the matcher.

3. Branching by simple strategies locally driven on responses and globally onsuccess and error counts.

VOCAL 797

1.2 The Methodology Behind TUTOR

TUTOR is the finest general-purpose AL. Its handling of graphics andresponse evaluation facilities are superb and well tailored for the intendedauthor (i.e., a subject-matter specialist who is not a computer programmer).As long as the instructional material is suited to the intended interpretationof the language, it is very convenient. We think, however, that the methodol­ogy behind TUTOR and other ALs breaks down.

We characterize the methodology behind the TUTOR language as thefollowing.

1. The AL should be general for all subject matters.

2. The AL should be conveniently usable hy subject matter specialists who arenot trained programmers.

3. The AL should contain such primitives as are needed for instruction with thenecessary programming in the general system.

4. Somewhat secretly, the AL is also usable as a general-purpose algorithmiclanguage. If the implementers did not provide the primitive you need, youcan create it yourself, bUl with difficulty.

The problem with this methodology is that it promises more than weknow how to deliver and hence will constrain us to be able to deliver lessthan we in fact know how to do. By requiring that the system be general,one restricts - pragmatically if not theoretically - what primitives can beadded. A special purpose primitive for use in proof checking is not likely tobe added by the system implementers since they are committed to general­ity. Since explicit programming is discouraged, the number of primitiveswill tend to grow anyway: TUTOR has several hundred primitive com­mands available, many of which affect the control structure of the code.

Likewise, this methodology is somewhat unclear about the status ofpermitting general computations in the language. Initial versions ofTUTOR did not allow the computation of arithmetic expressions or thewriting of subroutines. One by one these things were added because curric­ulumauthors wanted to do instructional material in areas where the built-inresponse evaluation primitives were inadequate. For example, suppose youwanted to write a lesson teaching the student how to evaluate arithmeticexpressions, say for an algebra course. You might get the AL maintainersto add some specific primitives for this operation; likely what you wouldend up doing would be wanting to write your own subroutines to do theresponse analysis, incorporating them into the lesson.

In many ALs, including earlier versions of TUTOR, computations otherthan those built into the language primitives were possible only by greatobfuscations. Fortunately, recent versions of TUTOR have had generalcomputation facilities; calculations and procedure definitions are reason­ably convenient. However, due to the fact that these facilities have been

798 SMITH

grafted onto the underlying TUTOR structure and due also to someimplementation decisions, a number of restrictions exist that would beconsidered strange. For example, a formal parameter in a proceduredefinition cannot be used elsewhere as a variable.

The study of the principles of programming languages has acknowledgedthe difficulty of making compromises in design process. For example, tak­ing the very clean PASCAL design and adding features to it to satisfy theDepartment of Defense's requirements for ADA has been a difficult andcontroversial undertaking; see Ichbiah (1979) for a discussion of the designof ADA.

In the case of TUTOR and other ALs, it seems [lear that writing suchgeneral computations as may be needed for instructional use is more diffi­cult in the AL-and requires more progragramming skill-than the samesubtask would be in a traditional programming language. As long as theprimitives provided are what you want, TUTOR is excellent. After thatpoint, it becomes a matter of programming against the system rather thanwith it.

1.3 Do We Need ALs At All?

One conclusion is that perhaps we should avoid the use of ALs alto­gether except for those cases where an already-existant AL is completelyappropriate. Instead, simply use the best available algorithmic language;this is exactly what has happened in many cases, although for divergentreasons.

Two of the commonest languages being used as ALs today are APL andBASIC (see Chambers & Sprecher, 1980). Both of these languages arewidely available in good interactive versions, allowing the author to writeand test instructional material on-line. While the writing and debuggingfacilities for TUTOR are excellent, the system is basically confined to aspecial-purpose CYBER machine running PLATO. Thus, it can be arguedthat the use of APL and BASIC is motivated by expediency.

Another group that has emphasized the use of general-purpose pro­gramming languages is the researchers concerned with the development of"intelligent" CAl systems. These groups have typically used the languagesand programming techniques from artificial intelligence research; amongthese groups, LISP predominates as the major AL Very few of the ICAI("Intelligent" CAl) systems have had more than a small curriculum or havebeen used with actual students.2

2Another group that we will not discuss here emphasizes the use of computers in educationas "dynamic media", emphasizing the possibility of students creating things with computersrather than being taught an organized curriculum. Thus, a good language for this use shouldencourage innovation and student understanding of dynamic processes, not the encoding ofinstructional sequences. Since this is sufficiently different than the underlying pedagogicalphilosophy we are assuming, we shall not discuss it further.

VOCAL 799

The difficulty with considering the AL to be a standard programminglanguage is that it misses the significant possibility that there are parts ofthe system that do not require a general-purpose programming language.Such parts, if they exist, should be abstracted out and codified in someuniform way.

1.4 A Methodology for AL Design

Many complex computer systems can profitably be thought of as ahierarchy or network of separate languages, each used for specifying partsof the system together with special-purpose interpreters for those lan­guages. For example, the error messages in an operating system may beculled out, put into a separate file in some simple syntax, and then aninterpreter can read the file when an errOr message is needed, indexing insome way. A better example is the various grammatical formalisms such asFloyd-Evans production languages that are used to specify the syntacticportions of many compilers.

A CAl system may have several such underlying languages, separatefrom the implementation language(s}. Consider the STRANDS program(Suppes, 1967), a classical CAl system developed at IMSSS. STRANDStaught arithmetic by giving the student drill-and-practiee exercises. Theexercises were arranged into a set of strands, or linear sequences of exer­cises associated with some concept in the curriculum such as column addi­tion or manipulating fractions. The instructional model emphasized whatwe (vaguely) referred to as BRANCHING above, namely, the problem ofselecting the next exercise; in this case, the model basically specified thatthe next exercise should be selected according to which concept the studentwas having the most difficulty with.

The STRANDS system is conceptually programmed in two languages,namely, the language for specifying the exercises in the strands and thelanguage for specifying the presentation and selection algorithms. Theexercises were coded in a special-purpose language, obtained by analyzingthe problem formats and developing a simple syntax that was adequate tothose formats; the exercise selection algorithm was coded in a standardprogramming language in which the interpreter for the exercise languagewas also written.3

The import of the example lies in the fact that the two languages reallywere necessary for the STRANDS project. Coding the exercise selection

3To be historically accurate, PDPIO assembly language was used for the programminglanguage and the exercises were preprocessed after authoring to make run-time access moreefficient. We shall regard the choice of how much to compile and how much to interpret asmostly an implementation decision. For most of the courses running at IMSSS over the years,preprocessors were built in order to speed up the runtime processing, by, compiling theoriginal source language into an internal language that is then interpreted at runtime. This istrue also of TUTOR.

800 SMITH

process into TUTOR would have been awkward since one would havebeen fighting the built-in sequencing algorithms; likewise, coding the exer­cises in an algorithmiclanguage would have been tedious.

The methodology that evolved at IMSSS for AL design, and that we nowrecommend, can be stated thus:

1. Conceptualize the entire system into a set of separate languages that arerelated to each other in terms of the functionality of the system.

2. Maximize the conceptual clarity of these languages as much as possible,simplifying the syntax and semantics. The criterion should be: can you ex­plain to the "author" what he is to do, regarding the interpreter for thelanguage as a logically specified "black box", and with only a minimal under­standing of the other languages associated wi~h other parts of the system?

3. Select already extant programming languages for those levels that seem toinvolve general programming and use the appropriate programming lan­guages.

4. Write special interpreters for those levels that are ll'1ore special purpose.

S. Facilitate the coding process by providing special~purpose processors, de­bugg"ers, and editors for the special-purpose levels.

In the next section, we describe the VOCAL language in terms of thismethodology and then turn to a more detailed discussion of the features ofVOCAL.

2. THE DESIGN CONSTRAINTS OF VOCAL

The main design goal ofVOCAL (for Voice Oriented Curriculum AuthorLanguage) was to be able to userandom-access computer-generated audioin the teaching of introductory logic. Developments of the previous decadehad produced a course in introductory logic that 'was in use to teach acOllege-level undergraduate course. Our tasks were: to find a useful con­ception of how audio could be used in this instruction, to redesign thesystem around this conception, and to test the efficacy of the audio-basedinstruction as compared to the same material presented on a CRT screenbut without audio.

The main notion of how audio might profitably be used was neitherdifficult to devise nor unnatural. We knew that instruction in logic in class­rooms and texts typically involves both object-level discussions of the syntaxof formulas and proofs and meta-level discussions of the meanings of asser­tions, and the techniques involved in proof constructions. For example, aninstructor might write a sample proof on the board and then point to partsof the proof and comment on it. It seems very natural to use random-accesscomputer-generated audio for this combination of object- and meta-leveldiscussion. In effect, the audio became a second channel ofcommunicationdescribing the meta-level of discussions about logic.

VOCAL 801

This also provided an opportunity to show that the uses of audio in CAlwere more general than had been commonly believed. The use ofcomputer­generated audio in such instructional areas as reading and foreign lan­guage instruction had been well established. Now, by showing how to useaudio in an area such as logic, we might extend the instructional uses ofthe audio technology.

The logic system had already been developed and used for several yearsto teach logic to Stanford undergraduates (see Suppes, Smith, & Beard,1975). T-his system already had several components which were written inseveral languages. The levels of the system included the following:

1. Curriculum: The curriculum for logic was written in a language calledMATHEX. It simply allowed the presentation of printed text, a number ofsimple response analysis operations such as multiple. choice problems, andaninterface to the proof checking system. Thus, theorems to be proved could bestated in this language.

2. Underlying logical theory: Since the logic system has some generality withrespect to the theories it can handle, a language, THRYEX, was available forstating the axioms, definitions, etc., of the theory.

3. Logical language: The .logic program is capable of accepting formulas in alanguage specially designed for the theory in question. These languages arespecified in a semantic grammar system called CONSTRUCT (Smith, 1974).

4. Proof checker: The main portion of the system is the proof checker. It waswritten in a high-level programming language, SAIL (Reiser, 1976).

5. Interpreters (and compilers): The special languages have interpreters (andcompilers) which were also written in SAIL.

We decided that we wanted to be able to specify such mixtures ofmaterial displayed on the screen with audio messages in order to imple­ment and test this idea for using two channels of communication. VOCAL,the AL we were developing, would then replace the MATHEX languagesas the way of expressing the sequences of text, exercises, and examples thatformed the curriculum.

The main new capabilities of expression that VOCAL needed were thefollowing:

1. Point to the screen: It should be easy to describe what is on the screen with~

out having to refer to screen coordinates. Some kind of picture of the screenand the things that are to go on it seemed appropriate. This would makeauthoring easier.

2. Sychronization of audio and visual messages: The synchronization of thedisplays on the screen and the audio messages·should be easily specifiable bythe author who could be guaranteed by the language that the synchroniza­tions would occur as expected.

3. Interface to the proof checker: Other matters, such as the interface to theother parts of the instructional system,. should be easily stateable in thelanguage.

802 SMITH

In the following subsections we discuss the main design decisions thatwere specifically made to implement the kind of use of audio that we had inmind. The specific decisions that were made are not as important in ourtreatment here as the design process itself. A more detailed discussion ofthe actual VOCAL language and the pragmatics of its use can be found inHinckley, Laddaga, Prebus, Smith, and Ferris (1977) and Davis and Petit(1978).

2.1 Syntax

The basic syntax of the VOCAL language is like LISP S-expressions(Weissman, 1967). This gives us a uniform syntax, simplifies the process ofediting and debugging exercises, and most importantly reduces the temp­tation to produce varied kinds of syntax for similar things. Some previousauthoring languages such as TUTOR and INST (Friend, 1971) seemed tohave too many special cases in the syntax.

2.2 Specification of the Display

We wanted an easy way for the author to specify where displayed textwould go on the screen. Clearly, adopting a coordinate notation like manygraphics languages (including TUTOR) would require much "translation"on the part of the curriculum author. Since the lessons would be preparedwith an already existent editing program, TVEDIT (Kanerva, 1973), whichpresented a screen of text as the user modified it, it seemed useful to us tohave a language that allowed the author to write pictures of the text thatwould appear on the screen and then specify the order in which parts ofthat frame would appear synchronized to the audio messages.

The first problem was how to point to parts of that text, saying whenparts of the text were to be typed, erased;overtyped with something else, orbrightened for emphasis (the CRTs permitted all of these things under con­trol of the host computer). A light pen would have provided one way ofpointing to parts of the screen during authoring, but we faced the addedproblem that the specification had to interleave audio messages with dis­played text to get the desired effect4

We adopted a format called a template which is basically a text string, as itwill appear on the screen, but including pointers to certain areas of thescreen. Then, the areas could be individually described in part of thelanguage that specified the screen and audio manipulations. For example,consider the template string in Figure 4.

4The TUTOR language has a fine way of specifying animation by having the author use atouch panel to point to parts of the screen; this is then compiled into TUTOR code whichstates the animation in terms of coordinates and a sequence of operations. The fact that wehad to also specify the audio messages persuaded us against such an approach for authoring,although we think it is a good approach.

VOCAL

"

(1) PA

(2) P~QBCCD

(2) means thatif P is trueEEEEEEEEEEEE

then Q is true

FIGURE 4. A VOCAL Template String.

803

%1 +

%3

_0;'-

The string gives both the text to be printed and the area labels allow­ing easy reference to portions of the text. In the sample template string,the lines that contain "%" are designated as the beginning, continuation, orend of an area spanning one or more complete lines. Lines that end with"%" mark the first line of an area that is to extend over two or more lines,with the next line that ends with "% (number)" being the final line of thatarea. Note that once a multiline area is begun with a line ending with "%"(or with "%<-"), the area is terminated ouly by a line ending with "%(number)". There may be intervening lines ending with "%<-" that aresimply continuation lines.

The lllost complex cases are the lines that end with either "%<E-" or"% (number) <-". The first of these says that the next line is not actually to

appear on the screen, but instead will contain subarea designators into thecurrent line. Thus, "if P is true'" is designated as a subarea (named "E"),consisting of a number of column positions. Likewise, a line that ends with"%{number)<-" says that (number) marks the current line(s) as an areawith name (number) but that, in addition, parts of the current line will bemarked by the area designators on the next line.

Note that area and subarea designators never appear on the screen forthe student. These designators are for use of the author. For example, if anauthor requested that areas 1, 2, and 3 of the sample template string abovebe displayed on the screen, the student would see the following:

(1) P(2) P~Q

804

(2) means that

if P is truethen Q is true.

SMITH

Thus, a template is a static picture of the screen, with pointers to areas.Specification of the dynamics of operation is done with a number of

opcodes that we included in the language. In the LISP-like syntax, theseopcodes took the form of lists with the operation code as the first elementof the list. Table 1 gives the opcades for simple display of areas; the meta­linguistic term (areas) refers to a list of area labels.

TABLE I

Area Display Commands in VOCAL

Displaycommand

(T (areas»)

(E (areas))

(B (areas))

(U (areas))

Description

The text associated with the areas in(areas) is displayed at the correctscreen coordinates.

Areas are erased.

The areas are brightened for emphasis.

Areas are "unbrighted" but the textis left displayed.

The template, and the commands governing it, are programmed intothe following VOCAL form:

(TEM (template-string) (actions»)

where (template-string) is as described above and (actions) is a list ofinstructions to be executed, which may include the display commands as inTable 1. In addition, audio commands, student response evaluation com­mands, and other utility commands may occur in (actions).

We realized that it would be useful to have a master template stringcontaining the basic layout of the screen and then to have an auxiliarysource of text to overprint on the basic layout. After some experimentationwith putting all of the text in a single template, we decided that having aform with two template strings was easier to understand. The followingVOCAL form has the effect of defining a master template and thensecondary source of strings for overtyping.

VOCAL

(TEM2 (master-template) (auxiliary-template) (actions»

805

For example, consider the VOCAL form in Figure 5. The interpretation ofthis form involves steps given in Figure 6. This demonstrates the meaningof the template strings and the run-time execution of the display commands.

(TEM2 "

The sentence:

If it is raining then it is wet.

is a conditional.

"

If it is not wet then it is not raining.

(T I 2 3) (OT 2 5»

FIGURE 5. A VOCAL TEM2 Form.

DEFINE the master template, and the auxiliarytemplate areas as shown;

Type out areas 1,2 and 3--i.e., "(T I 2 3)";

Overtype area 5 (from the auxiliary template) ontothe space occupied by area 2-i.e., "(OT 2 5)";

FIGURE 6. Approximation of Code in Figure 5.

%1

%2

%3

%5

The complete list of overtype display commands is given in Table 2. Theexact rules for this operation are spelled out in the VOCAL manual. Inparticular, overtyping a new area onto an old area causes any old subareadefinitions to become inactive and instead supplants the new subareadefinitions. We took care in the design to make the rules governingtem­plate definition and execution very clear.

806 SMITH

This raises the following points about AL design:

1. The language of the AI.. is "short hand" for some programmed execution,for example, VOCAL apcades for handling the printing and overtyping ofareas of the screen. It is very important to define these commands in such away that the author can understand the command without getting the sensethat it involves a lot of special casing and kludgery. Our definition of themeaning of subareas after overtyping is such an example. 'Vithout thisrestriction, the meaning of the commands became quite incoherent, not tomention presenting possible implementation problems.

2. It is likewise important to make the set of opcodes in the language habitable,in the sense that the operations allowed represent some coherent space oftransformations of basic ideas. For example, since we allowed both bright­ening an area and overtyping an area, the concept of "over-brightening"presented itself. We had to define what this meant, assuming reasonableexpectations on the part of authors, and had to solve some implementationproblems that the definition caused.

3. Most computer languages inherently contain compromises in their design.ALs are no exception Lo this rule. For example, by adopting the compromisesin the notions of "area'! and "display", we make it relatively clear for theJesson author, but at the expense of making it hard to extend the languagewith respect to display handling.

TABLE 2

VOCAL Overtype Commands

Overtypecommand

Description

(OT (oldarea) (newarea»)

(OE (oldarea) (newa"a»)

(OB (oldarea) (newarea»)

Overtype the text in (newarea) onto thespace occupied by {oldarea).

This erases the space defined by (newarea)on the screen space occupied by (oldarea).

Brightens the areas defined by (newarea) onthe screen space occupied by (oldarea).

2.3 Presentation of Audio Messages

The presentation of audio messages uses a pre-programmed library ofaudio routines developed by Sanders, Benbassat, and Levine. (See, forexample Sanders, Benbassat, & Smith, 1976; Sanders, Levine, & Laddaga,1979; Levine & Sanders, 1981.)5 The simplest way to get an audio message

50riginally, the messages were separately recorded by a human speaker. The VOCALcompiler made up lists of messages that needed to be recorded so that runtime-execution onlyinvolved playing a single sound for each message of a certain length. In a later version, due tothe work on prosody of Arvin Levine, it was possible to compile a complete sentence withreasonable prosody from only the recorded versions of the words in that sentence. This isdiscussed in Levine and Sanders (1981).

VOCAL 807

spoken to the student is to make a subroutine call with the text string ofcharacters to be converted to a sound, for example,

SPEAK ("The first part of the conditional is an antecedent.");

As we mentioned, it was necessary to guarantee synchronization of thesounds with the displayed text; in addition, the author had to be able tospecify in a simple way what that specification was. We developed a syntaxfor the S (for "Speak") opcode that was fairly successful for authors. Thesyntax allowed the author to specify a list of audio messages interleavedwith type and overtype commands that would cause display; the conventionwas that the interpreter would guarantee synchronization.

Consider the template in Figure 7 which contains an embedded "Speak".The action of the interpreter is given approximately by the ALGOL-likecode in Figure 8. In the above, the pseudo-ALGOL construction "DO

(TEM "

A BACCB

(S "The formula" (T ABC) "is a conditional.")(S "The arrow" (B C) "indicates this."»)

FIGURE 7. Template with SPEAK Opcodes.

DEFINE template areas as specified;

SPEAK ("The formula")WAIT for speak to be accomplished;DO concurrently:

TYPE out areas A, B, and C;SPEAK ("is a conditional");

SPEAK ("The arrow");WAIT;BRIGHTEN area C;DO concurrently:

WAIT;SPEAK ("indicates this");

FIGURE 8. Approximation of Figure 7.

808 SMITH

CONCURRENTLY" means that the embedded statements are done at thesame logical time (using the separate hardware of the displays and theaudio system).

This left to the VOCAL interpreter to do the processing in such a way asto carry out the specified synchronization; this turned out to involve modifi­cations to the operating system, since the various actions of sending displaytext and audio messages were subject to various effects of time-sharing andscheduling in the TENEX environment. The problem was solved by Sand­ers, Roberts, and Prebus. In terms of the design of VOCAL, the importantconsideration is that it was identified as a problem that the implementationneeded to address rather than being left as something that the curriculumahthor had to be concerned with.

2.4 Other Commands Related to Main Design Issues

Several other commands in VOCAL address ancillary issues of the maindesign problem. These commands are given in Table 3.

TABLE 3

Other Synchronization Commands

Synchronizationcommand

(W (num))

(HOLD)

(HOLD (prompt-string)(actions)

Description

A programmed synchronization. Waits for{num} milliseconds.

A student-initiated synchronization. Theprogram stops until the student types acommand, which can ask it to repeat orgo on to the next form.

A student-initiated synchronization.(prompt.string) is the prompt printedout to allow the student to eitherrequest a repeat of (actions) orcontinue to the next form.

The W command lets the author specify a wait. The HOLD commandallows the student to do the synchronization. In particular, consider thefollowing HOLD form:

(HOLD "see this again" (T A E»

would be executed as approximately the ALGOL program in Figure 9.HOLD was used fairly frequently by the curriculum authors since it alloweda sequence of commands to be grouped together and repeated as a unit by

VOCAL 809

the student. It allowed the student to repeat the hearing of messages andscreen animation that he may have missed.

2.5 Other VOCAL Constructions in Support of Teaching Logic

VOCAL contains a number of constructs that support the basic instruc­tional design of the logic course. These features are briefly described here.These constructions include:

1. Lessons divided into exercises. The structure of the curriculum is similar to thatdescribed in Suppes, Smith, and Beard (1975).

2. Questions asked of the student according to a number of simple question­answer formats.

3. Proof-checker related exercises that use the proof checking system and com­munication with the proof checker.

The following subsections discuss these features of the language.

COMMENT assuming we are inside a template definition;

HOLD.LOOP:Type areas A, B;

ASK.AGAIN:Type out "[Type ESC to go on, CTRL-A to see this again.]

in a region below the template on the screen;IF student types the ESCape key on the terminal THEN

GOTO DONEELSEIF student types the control-A key THEN

GOTO HOLD.LOOPELSE

GOTO ASK.AGAIN;DONE:

FIGURE 9. Approximation of a HOLD Opcode.

Structural commands. The VOCAL forms given in Table 4 concern thestructure of the curriculum, division into lessons and exercises, and state­ment of the versions of the code designed for audio, display, and standardTeletype use'

The LESSON opcode starts lesson number (number). The string "de­scription" is a single string that is printed at the top of the screen at the startof the lesson; (actions) is any sequence of VOCAL commands (not includ-

GThe audio and display versions were used for experiments on student preference.

810 SMITH

TABLE 4

Structural Forms in VOCAL

(AUDIO (actions))(DPY (actiom))(TTY (actiom)(NONAUDIO (actiom))(LESSON (number) "description" (actions)(EXERCISE (number) "description" (actions))(BEGIN (list of actions)(GOTO (lessonnumber) (exercisenurnber)(CALL (lessonnumber) (exercisenumber)(CHOICELESSON (lessonnumberlist)(BRANCHLESSON "text" (lessonnumber)(RAND (action) (action) ... (action))

ing LESSON or EXERCISE) that is to be executed. The intended use ofthis command is to give an introduction to a new lesson; the apcade is usedonly once in a particular lesson segment of the course.

The EXERCISE opcode defines the (actions) to be executed for anexercise of number (number) within a lesson. "description" is a single lineprinted at the top of the screen during this exercise. An EXERCISE is thesmallest unit of the curriculum that can be randomly accessed.

A typical lesson is like:

[LESSON n "lesson description string" (actions)][EXERCISE 1 ".. ." (actions)][EXERCISE 2 "..." (actions)]

[EXERCISE n "..." (actions)][GOTO next-lesson]

where the [GOTO next-lesson] at the end links this lesson to the nextlesson of the course .

The BEGIN opcode allows two or more commands to occur together.Commands within the BEGIN are executed in sequence. The AUDIO,DPY, TTY, and NOAUDIO opcodes are implicitly conditional opcodes thatexamine at execution time which version of the curriculum the student isusing. AUDIO surrounds code intended only to be executed if the audiosystem is available and selected. DPY surrounds code that is used if thestudent is doing the display version that runs on a CRT terminal but with­out audio; the code within TTY is selected if the student is running withoutaudio on some terminal that does not have display capabilities; NOAUDIOis an abbreviation for either DPY or TTY. The presence of these condi­tional opcodes is mostly an artifact of the experiments we were performingto determine the efficacy of audio in CAL

VOCAL 811

Several apcades control the connection of exercises and lessons in thecurriculum. This "branching" is very primitive in the logic program; thecurriculum is mainly a linear progression of exercises and instructionalmaterial, since this aspect of the course was never emphasized.

The GOTO opcode chains lessons together. The CALL opcode inter­prets an exercise for a student but does not require any answers from thestudent. It is used from within answer evaluation code to provide a degreeof remediation.' CHOICELESSON allows the student to decide on one ofseveral lessons. This apcade is used to implement the logic course's options,whereby a student can take the course for one of several grades dependingon which material he does. BRANCHLESSON checks to see if the studenthas answered more than 75% of the exercises correctly in the lesson up tothis point; if so, the student is allowed to skip ahead without completing therest of the lesson.s

The RAND opcode selects at "random" one of the actions and executesthat one. This would be used to give randomly generated exercise selec­tion; it is not however substantively used in the logic course.

Question-asking opcodes. We implemented a numher of opcodes to askquestions and evaluate student responses. These opcodes have much thesame effect as 'judging" opcodes in many ALs such as TUTOR.

The C and CQopcodes allow the statement of a question to the student,followed by a number of ways in which the answer can be evaluated, andwhat messages and responses should be given to the student. The messagescan combine display and audio.

For example, consider the following:

(Q INIT

AHINTL

«S "What is the first letter of the alphabet?")(T "Type the letter indicating your answer."))

(ANS "A")«S "The letter before B") (S "Think harder"))

The INIT tag labels actions to be done at the beginning. The A labels theactual response evaluation to be performed-in this case, stating that theanswer should be the string "A" exactly. HINTL gives a list of hints that thestudent can exhaust.

The Q opcode contains a numher of such tags which label the actions tobe taken. For example, CA lahels an action to be taken at the point that the

7There is also a BROWSE mode in the system that permits the student to examine someprevious part of the curriculum. It is not discussed here in any detail (see Hinckley, Laddaga,Prebus, Smith, & Ferris, 1977).

8Because the substantive exercises in the logic course involve the construction of proofs,which are not optional in this way, there is no substantive use of BRANCHLESSON in thelogic course.

812 SMITH

student gets the question correct; WA if wrong; CAS gives a series of pairsof correct answers and actions to be evaluated.

The VOCAL opcodes for evaluating student responses are simple, in­deed, semantically much simpler than the judging facilities of TUTOR.This was possible because the main source of student interaction occurs inthe construction of proofs and not answering questions. We were able,however, to develop a set of question-asking and answer evaluation primi­tives that were well-structured in terms of the modern theory of program­ming language design. The use of the tags within a structured constructioncreates, we believe, a more readable coding of the. instructional materialthan some previous authoring languages such as INST (Friend, 1971).

Interface to the proof checker. Most of the pedagogical interest in thecourse is associated with the proof checker and the several hundred proofsthat the student is asked to perform during the course.

The proof checker itself is coded in high-level programming languages.The current proof checkers are programmed in SAIL and LISP, both ofwhich are languages long associated with research in artificial intelligence.VOCAL contains opcodes that allow the curriculum author to specify theexercises that are in fact to be performed in association with the proofchecker. These exercises include both the construction of proofs for prov­able assertions and the construction of counterexamples for assertions thatare not provable. Counterexamples are demonstrated by giving interpreta­tions and then showing the justifying proofs for the interpretations.

For example, consider the DERIVE opcode, whith has the followinggeneral syntax:

(DERIVE "goal" (tag) (action) (tag) (action) ... )

"Goal" is the string representation of a formula to be derived. This is arequired argument and must immediately follow the opcode. The otherarguments to DERIVE consist of pairs of (tags) and (actions), all of whichmay be defaulted and may occur in any order. The following tags areallowed: .

1. IN IT (actions). These actions will be done when the DERIVE opcode isbegun.

2. PREML ("premise'" "premise" ...). This is a list of string representations ofthe premises for the derivation.

3. HINT (action). The ·student can request a hint during his effort to prove thederivation. If a hint is present in the pre-coded curriculum, then the (action)is executed.

4. HINTL «action) (action) ...). The HINTL tag allows several hints to beincluded by the curriculum author. The hints will be given to the student inthe order specified, as the student requests assistance.

VOCAL 813

5. RESTL (restrictionlist). This is the list of restrictions on the rules of infer­ence, etc., that the student must or must not use in this derivation. Thisallows the curriculum author to control the introduction of rules ofinferenceand is used specifically when a rule is shown to be derivable from other rules.

6. DONE (doneaction). If this tag is present it indicates the action to be per­formed when the student has completed the derivation.

For example, consider the exercise in Figure 10. The VOCAL form isapproximated by the algorithm in Figure 11. There are several opcodesthat have the same syntax as the DERIVE command. An overview of thecurriculum and the types of derivation problems is given in Suppes, Smith,and Beard (1975).

(DERIVE "W Q"PREML ("W p" "p .... Q")INIT (S "Try this exercise; it is like the last one.")HINTL (T"Start by using the WP rule; use it to add W.")

(T"You will need to use the AA rule to do this."))DONE «(T"Good. Now we'll take a closer look at the two rules."))))

FIGURE 10. A DERIVE-type Exercise.

INIT SPEAK (using audio)"Try this exercise; it is like the last one."

Call the proof checker, asking the student to derive:W.... Q

from the premises

W pP Q

(supply the hints to the proof checker);[The stud~nt continues to interact with theproof checker until he finishes the proof, ingeneral.]

DONE TYPE (on the display)"Good. Now we'll take a closer look at the two rules.";

FIGURE 11. Approximation of DERIVE Opcode.

814 SMITH

In addition, a number of opcades have the effect of setting variousmodes and variables in the proof checker. For example, the logic coursedeals with a number of different logical theories, such as Boolean algebra,probability theory, social decision theory, as well as the basic theories ofpropositional and predicate calculus. The curriculum author specifieswhich theory is in use at a given point in the curriculum. The theoriesthemselves are specified in a related language THRYEX (see Hinckley,Laddaga, Prebus, Smith, & Ferris, 1977).

3. VOCAL AND THE METHODOLOGY OF AL DESIGN

We have advanced the idea that instructional systems should be built ofhierarchies of languages, some of which are limited and special purpose incharacter, and that those languages should be defined by a process ofmodularizing the total space of what the computer needs to be told in orderto implement a certain set of instructional ideas. In the case of VOCAL,those instructional ideas concentrated around the use of audio in teachingthe construction of proofs and interpretations in logic.

It may be tempting to suggest that the portion of the total system that iswritten in VOCAL is not the interesting part. Certainly, from a computer­science point of view, the proof checker and the MISS audio system are themore interesting parts. This belies the significance of the curriculum. Thecurriculum is one of the -largest single parts of the system; it occupies moredisk storage than the source programs for the proof checker and run-timeinterpreter. Writing and modifying the curriculum has also occupied manypeople over the years. We would estimate that recreating the curriculumfrom scratch would be more time-consuming and expensive, at this point,than recreating the proof checker.' One thing that the research at IMSSShas emphasized-and rightfully so-is the importance of a complete andcoherent curriculum as a part of the CAL system.

The methodology we are advocating for AL design assumes that wereally do not know in detail what computational facilities will be needed toimplement new instructional ideas and more kinds of curricula. Thus, it issimply too early to freeze the development of authoring languages by devel­oping general-purpose, exportable ALs. Instead, we need to accept a designmethodology that lets us be flexible with respect to the entire architectureof the system with parts programmed and coded in different languages.

This methodology is not totally pessimistic with regard to the transport­ability of instructional systems, however. There are two related strategies

UThis is perhaps because we learned some unifying principles of proof-checker designfrom the previous proof checkers and these principles could be applied to the construction ofa new proof checker. The same does not seem to hold for the curriculum.

VOCAL 815

that we can now pursue to assist in both the development and the transportof CAl systems. These are:

1. Encourage the development of high-level programming languages designedfor the development and deployment of complex systems. For example, theADA language, with its standards of modularity and portability, strikes us assuch a programming language. A good language should be embedded withina program development environment, including display-oriented text editorsand testing and debugging facilities. We discovered that SAIL and LISP,running under TENEX and with such associated system tools as TVEDIT,was an approximation to such a programming environment; the ADA devel­opment effort also recognizes the need for a complete support system.

2. The second thing that one can do is to continue looking for instructionalideas that do in fact generalize across curricula and pedagogical approaches.One such idea from the TUTOR language is the techniques of pattern­matching for the evaluation of student responses. A specific contribution ofVOCAL, we would claim, is the description of the interleaving of audiomessages and display messages.

Such ideas - once given coherent definition - can then be embeddedwithin subroutine packages that facilitate the construction of special­purpose ALs. CAl research has been too hasty in formalizing ideas intoauthoring languages and not reflective enough about what techniques areconvenient for the author and instructionally useful.

REFERENCES

Chambers, j., & Sprecher, J. Computer-assisted instruction: Current trends andcritical issues. Communicatiom of the ACM, 1980, 23, 332-342.

Davis, M. K, & Pettit, T. Using VOCAL: A guide for authors (Tech. Rep. 296). Stan­ford, Calif.: Stanford University, Institute for Mathematical Studies in the SocialSciences, 1978.

Friend, j. INSTRUCT coders' manual (Tech. Rep. 172). Stanford, Calif.: StanfordUniversity, Institute for Mathematical Studies in the Social Sciences, 1971.

Hinckley, M., Laddaga, R., Prebus, J., Smith, R., & Ferris, D. VOCAL.' Voice orientedcurriculum author language (Tech. Rep. 291). Stanford, Calif.: Stanford University,Institute for Mathematical Studies in the Social Sciences, 1977.

Ichbiah,j. D. Rationale for the design of the ADA programming language. SIGPLANNotices, 1979, 14.

Kanerva, P. Tvedit manual. Unpublished manuscript, Stanford University, Institutefor Mathematical Studies in the Social Sciences, 1973.

Levine, A., & Sanders, W. R. The MISS speech synthesis system. In P. Suppes (Ed.),University-level computer-assisted instruction at Stanford: 1968-1980. Stanford, Calif.:Stanford University, Institute for Mathematical Studies in the Social Sciences,1981.

Reiser, J. F. SAIL (Stanford Artificial Intelligence Laboratory Memo AIM 289).Stanford, Calif.: Stanford University, Stanford Artificial Intelligence Laboratory,1976.

816 SMITH

Sanders, W. R., Benbassat, G. V., & Smith, R. L. Speech synthesis for computer­assisted instruction: The MISS system and its applications SIGeVE Bulletin,1976, 8,1, 200-211.

Sanders, W. R., Levine, A., & Laddaga, R. The use of MISS in computer-based in­struction. In CmnjJII(er-basededucation: j\1.i.<ision of the future (Proceedings of the1979 ADCIS conference). San Diego, Calif.: 1979.

Sherwood, B. A. The TUROE Language (Technical Report). Urbana, Ill.: Universityof Illinois, Computer-based Education Research Laboratory, 1974.

Smith, N., A question-answering system for elementary mathematics (Tech. Rep. 227).Stanford, Calif.: Stanford University, Institute for Mathematical Studies in theSocial Sciences, 1974.

Suppes, P. Some theoretical models for mathematics learning. Journal of Researchand Development in Education, 1967, 1,5-22.

Suppes, P., Smith, R. L., & Beard, M. University-level CAl at Stanford: 1975. (Tech.Rep. 2.65). Stanford, Calif.: Stanford University, Institute for MathematicalStudies in the Social Sciences, 1975.

Weissman,C. LISP 15 primer. Belmont, Calif.: Dickenson, 1967.

.