TUTOR, also known as PLATO Author Language, is a programming language developed for use on the PLATO system at the University of Illinois at Urbana-Champaign beginning in roughly 1965. TUTOR was initially designed by Paul Tenczar for use in computer assisted instruction (CAI) and computer managed instruction (CMI) (in computer programs called "lessons") and has many features for that purpose. For example, TUTOR has powerful answer-parsing and answer-judging commands, graphics, and features to simplify handling student records and statistics by instructors. TUTOR's flexibility, in combination with PLATO's computational power (running on what was considered a supercomputer in 1972), also made it suitable for the creation of games — including flight simulators, war games, dungeon style multiplayer role-playing games, card games, word games, and medical lesson games such as Bugs and Drugs (BND). TUTOR lives on today as the programming language for the Cyber1 PLATO System, which runs most of the source code from 1980s PLATO and has roughly 5000 users as of June 2020.
Origins and development TUTOR was originally developed as a special purpose authoring language for designing instructional lessons, and its evolution into a general purpose programming language was unplanned. The name TUTOR was first applied to the authoring language of the PLATO system in the later days of Plato III. The first documentation of the language, under this name, appears to have been
The article Teaching the Translation of Russian by Computer gives a snapshot of TUTOR from shortly before PLATO IV was operational. Core elements of the language were present, but commands were given in upper case, and instead of using a general mechanism, support for alternative character sets was through special command names such as WRUSS for "write using the Russian character set."
Through the 1970s, the developers of TUTOR took advantage of the fact that the entire corpus of TUTOR programs were stored on-line on the same computer system. Whenever they felt a need to change the language, they ran conversion software over the corpus of TUTOR code to revise all existing code so that it conformed with the changes they had made. As a result, once new versions of TUTOR were developed, maintaining compatibility with the PLATO version could be very difficult.
Control Data Corporation (CDC), by 1981, had largely expunged the name TUTOR from their PLATO documentation. They referred to the language itself as the PLATO Author Language. The phrase TUTOR file or even TUTOR lesson file survived, however, as the name of the type of file used to store text written in the PLATO Author Language.See, for example,
Structure of a TUTOR lesson A TUTOR lesson consists of a sequence of units where each unit begins with the presentation of information and progress from one unit to the next is contingent on correctly answering one or more questions. As with COBOL paragraphs, control may enter a TUTOR unit from the preceding unit and exit into the next, but units are also callable as subroutines using the do or join commands.
Here is an example unit:From
unit math at 205 write Answer these problems
3 + 3 =
4 × 3 =
arrow 413 answer 6 arrow 613 answer 12
Several things should be immediately apparent from this example.
First, TUTOR is a fixed format language. Each line begins with a command name, which must fit within a fixed 8-character field. The arguments to that command (the tag) begin at the 9th character. Although a tab key was used to get to the 9th column, it generated spaces as PLATO had no tab character. In some cases, such as the write command above, the tag may consist of multiple lines. Continuation lines are either blank or have a leading tab. Screen coordinates are presented as single numbers, so 205 refers to line 2 column 5, and 413 refers to line 4 column 13.
What may not be apparent is the control structure implicit in this unit. The arrow command marks the entrance to a judging block This control structure is one of TUTOR's unique features.
Unique features TUTOR contained a number of unique features. The following list is not intended as a substitute for a TUTOR manual, but merely highlights the most interesting, innovative, and sometimes confusing features of the language.
Answer judging A judging block in TUTOR is a control structure that begins with an arrow command and ends with the next arrow, endarrow or unit command. The arrow command also prompts for input, with the special arrow character (resembling "▷") displayed as a prompt at the indicated screen coordinates. In effect, a judging block can be thought of as a backtracking control structure where the student may make multiple attempts to answer a question until a correct answer allows forward progress.
Judging pattern matching Each judging block consists of a sequence of pattern matching commands, each of which introduces a (possibly empty) block of commands to be executed if that pattern matches. The two most common pattern matching commands were answer and wrong. These had identical pattern matching semantics except that answer judged a student response to be correct if it matched, while wrong judged a student response to be incorrect.
The tag fields on the answer and wrong commands consisted of lists of optional, required and alternative words. consider this example:From
answer <it, is,a, it's, figure, polygon> (right, rt) (triangle, triangular)
This would match answers such as "it is a right triangle" or "it's a triangular figure" or just "rt triangle". It would not match "sort of triangular" because the words "sort of" are not listed as ignored, and it would not match "triangle, right?" because the order is wrong.
The pattern matching subsystem recognized spelling errors, so the words "triangel" or "triangl" would match the example pattern. The lesson author could use the specs command to set how pedantic the system was about spelling errors.
The pattern matching algorithms used by various TUTOR implementations varied in detail, but typically, each word in the input text and each word in the pattern were converted to bit vectors. To see whether a word of student input matched a word of the pattern, the Hamming distance between the two bit vectors was used as a measure of the degree of difference between the words. Bit vectors were typically 60 or 64 bits long, with fields for letter presence, letter pair presence, and the first letter. As a result, the number of one bits in the exclusive or of two such bit vectors approximated the extent of the phonetic difference between the corresponding words.
Judging control structures All early presentations of the control structure of a TUTOR judging block were confusing. In modern terms, however, a judging block can be described as an iterative control structure that exits when the student input is judged correct. The body of this control structure consists of a series of cases, each introduced by a pattern matching command such as answer or wrong. All output produced by the body of the judging loop in the previous cycle is erased from the screen prior to the next cycle.
Consider this example:From
wrong <it, is,a> square at 1501 write A square has four sides.
In the event that the student inputs "square" or "a square", the answer is judged to be incorrect, and the text "A square has four sides." is output starting at line 15 column 1 on the screen. This output remains on the screen until the student begins to enter a new answer, at which point, it is erased so that the response to the new answer can be computed. The mechanism by which the display screen rolls back to its previous state varies from implementation to implementation. Early implementations operated by switching the terminal into erase mode and re-executing the entire case that had matched. Some later implementations buffered the output produced during judging so that this output could be erased.
The join command was a unique form of subroutine call. It was defined as being equivalent to textual substitution of the body of the joined unit in place of the join command itself. As such, a joined unit could contain part of a judging block. Thus, while the judging block is conceptually an iterator enclosing a series of cases, this block may be arbitrarily broken into subroutines. (An alternative subroutine call, the do command, conformed to the usual semantics associated with subroutine calls in other programming languages.)
Graphic and display commands The PLATO IV student terminal had a 512 by 512 pixel plasma display panel, with hardware support for point plotting, line drawing, and text display. Each pixel on the PLATO IV terminal was either orange or black. The CDC PLATO V terminal used a monochrome black and white CRT to emulate the plasma panel. The built-in character set had 4 sets of 63 characters, each 8 by 16 pixels, half of these were fixed, half were programmable. The Tutor language provided complete support for this terminal.
There were two coordinate systems
Coarse coordinates were specified in terms of the rows and columns of text. The coarse coordinate 1501, for example, was a reference to line 15 character 1, where the upper left character on the screen was at location 101 and the lower right character was at 3264. Fine coordinates were specified as X and Y coordinates relative to the lower left corner of the screen. The fine coordinate 0,511 specified the upper left corner of the screen, while 0,496 was equivalent to the coarse 101, allowing for the 16 pixel height of a character and the fact that characters were plotted relative to their lower left corner.
Drawing commands The following example illustrates some of Tutor's drawing commands.From
draw 1812;1852;skip;1844;1544 circle 16,344,288 draw 1837;1537;1535;1633;1833
Note the use of semicolons to separate successive coordinates on the draw command. This allows unambiguous use of comma-separated fine coordinates. Normally, the draw command connects consecutive points with line segments, but by putting skip in the tag, the draw command could be made to conceptually lift its pen.
The tags on the circle command give the radius and fine coordinates of the center. Additional tags could specify starting and ending angles for partial circles.
Hand composing draw commands is difficult, so a picture editor was included in the PLATO system by 1974 to automate this work. This could only deal with drawing commands with constant coordinates.
Text rendering commands The following example illustrates some of the text rendering tools of Tutor.From
unit title size 9.5 $$ text 9.5 times normal size rotate 45 $$ text rotated 45 degrees at 2519 write Latin size 0 $$ return to normal writing rotate 0 at 3125 write Lessons on Verbs
Text rendered in size zero rotation zero used the built-in character rendering hardware of the PLATO terminal, while rendering with nonzero size and rotation was done with line segments and therefore significantly slower due to the speed of the communication link to the terminal.
Control structures Aside from its unique answer judging mechanisms, TUTOR's original set of control structures was rather sparse. In the mid 1970s, this shortcoming was addressed by introducing if, endif blocks with optional elseif and else sections. The semantics of these control structures was routine, but the syntax inherited the mandatory indentation of the Tutor Language, presaging that of Python and adding a unique nonblank indent character to distinguish indenting from continuation lines.
This is illustrated in the following example:From
if n8<4 . write first branch . calc n9⇐34 elseif n8=4 . write second branch . do someunit else . write default branch . if n8>6 . . write special branch . endif endif