TUTOR

Short description: Programming language

TUTORParadigm| imperative (procedural)

|

Designed by| Paul Tenczar & Richard Blomme[1]
Developer| Paul Tenczar & University of Illinois at Urbana-Champaign
First appeared| 1969 (1969)
Typing discipline| none
Major implementations
TUTOR, Micro-TUTOR
Influenced
TenCORE, USE (Regency Systems)

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,[2] which runs most of the source code from 1980s PLATO and has roughly 5000 users as of June 2020.

## Contents

* 1 Origins and development
* 2 Structure of a TUTOR lesson
* 3 Unique features
* 3.1 Answer judging
* 3.1.1 Judging pattern matching
* 3.1.2 Judging control structures
* 3.2 Graphic and display commands
* 3.2.1 Drawing commands
* 3.2.2 Text rendering commands
* 3.3 Control structures
* 3.4 Expression syntax
* 3.5 Memory management
* 3.5.1 Basic memory resources
* 3.5.2 Defining symbolic names
* 3.5.3 Arrays, packed arrays, and text manipulation
* 3.5.4 Parameter passing
* 3.5.5 Local variables
* 4 Other implementations
* 5 References
* 6 External links

## 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 TUTOR Manual, CERL Report X-4, by R. A. Avner and P. Tenczar, Jan. 1969.

The article Teaching the Translation of Russian by Computer[3] 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.[4] As a result, once new versions of TUTOR were developed, maintaining compatibility with the PLATO version could be very difficult.[5]

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.[6]

## 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 page 5 of the TUTOR User's Memo, March 1973 (Computer-based Education Research Laboratory, University of Illinois at Urbana-Champaign):

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 for the command name. The arguments to that command (the tag) begin at the 9th character. Although a tab key was be 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 exercise 4-1 in the 1973 TUTOR User's Memo:

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.[7]

#### 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 exercise 4-1 of the 1973 TUTOR User's Memo:

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 (page 21, 1973 TUTOR User's Memo). 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[8] 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 (see page II-1 of The TUTOR Language by Bruce Sherwood):

* 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.[9]

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.[10] 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.[11]

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 page S5 of the Summary of TUTOR Commands and System Variables (10th ed) by Elaine Avner, 1981:

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

(The assignment arrow in the `calc` statement is not rendered correctly in some browsers. It appears similar to <= but as one character. It had a dedicated key on the PLATO IV keyboard.)

The same syntax was used for `loop`, `endloop` blocks with semantics comparable to while loops in conventional programming languages. This is illustrated in the following example, from page S6 of the Summary of TUTOR Commands and System Variables (10th ed) by Elaine Avner, 1981:

loop    n8<10
.       write   within loop
.       sub1    n8
reloop  n8≥5
.       write   still within loop
.       do      someunit
outloop n8<3
.       write   still within loop
endloop
write   outside of loop

Note that the `reloop` and `outloop` commands are somewhat analogous to the `continue` and `break` statements of languages based on C, except that they must sit at the indenting level of the loop they modify, and they have a condition tag that indicates when the indicated control transfer is to take place. This makes the construct more powerful than in other languages, because any line of the inner loop could terminate or reloop several outer loops with one statement.

### Expression syntax

TUTOR's expression syntax did not look back to the syntax of FORTRAN, nor was it limited by poorly designed character sets of the era. For example, the PLATO IV character set included control characters for subscript and superscript, and TUTOR used these for exponentiation. Consider this command (from page IV-1 of The TUTOR Language, Sherwood, 1974):

circle  (412+72.62)1/2,100,200

The character set also included the conventional symbols for multiplication and division, `×` and `÷`, but in a more radical departure from the conventions established by FORTRAN, it allowed implicit multiplication, so the expressions `(4+7)(3+6)` and `3.4+5(23-3)/2` were valid, with the values 99 and 15.9, respectively (op cit). This feature was seen as essential. When students typed in a numeric answer to a question, they could use operators and variables and standard algebraic notation, and the program would use the TUTOR "compute" command to compile and run the formula and check that it was numerically equivalent (or within the floating point roundoff error) to the correct answer.

The language included a pre-defined constant named with the Greek letter pi (π), with the appropriate value, which could be used in calculations. Thus, the expression `πr2` could be used to calculate the area of a circle, using the built-in π constant, implicit multiplication and exponentiation indicated by a superscript.

In TUTOR, the floating-point comparison `x=y` was defined as being true if `x` and `y` were approximately equal (see page C5 of PLATO User's Memo, Number One by Avner, 1975). This simplified life for mathematically naïve developers of instructional lessons, but it occasionally caused headaches for developers of numerically sophisticated code because it was possible that both `x<y` and `x≥y` could be true at the same time.[12]

### Memory management

As an authoring language, TUTOR began with only minimal memory resources and only the crudest tools for manipulating them. Each user process had a private data segment of 150 variables, and shared common blocks could be attached, allowing inter-user communication through shared memory.

On the PLATO IV system, words were 60 bits, in keeping with the CDC 6600 family of computers. Some later implementations changed this to 64 bits.[13]

#### Basic memory resources

The private memory region of each process consisted of 150 words each, referred to as student variables; the values of these variables were persistent, following the individual user from session to session. These were addressed as `n1` through `n150` when used to hold integer values, or as `v1` through `v150` when used to hold floating point values.[14]

A TUTOR lesson could attach a single region of up to 1500 words of shared memory using the `common` command. Each lesson could have an unnamed temporary common block containing variables shared by all users of that lesson. Such blocks were created when a lesson came into use and deallocated when the lesson became inactive. In contrast, named common blocks were associated with a block of a lesson (a disk file). Shared memory was addressed as `nc1` through `nc1500` (for integers) or `vc1` through `vc1500` (for floating point numbers).[15]

Where 150 student variables was insufficient, a lesson could use the `storage` command to create an additional private memory segment of up to 1000 words. This segment existed in swap space only, but it could be mapped to student variables or common variables. For example (from page X-11 of The TUTOR Language, Sherwood, 1974):

common  1000
storage 75
stoload vc1001,1,75

This example defines `nc1` to `nc1000` as a shared unnamed common block, while `nc1001` to `nc1075` are private storage.

#### Defining symbolic names

The Tutor `define` command was very similar to the C `#define` preprocessor directive. This was the only way to associate mnemonic names with variables. It was up to the programmer to statically allocate memory and assign names to variables. Consider this example from page 17 of the TUTOR User's Memo -- Introduction to TUTOR, 1973"

define  mynames
first=v1, second =v2
result=v3

This creates a set of definitions named `mynames` defining three floating point variables. Users were advised that "there should not be any v3's or v26's anywhere in your lesson except in the `define` statement itself. Put all your definitions at the very beginning of the lesson where you will have ready reference to which variables you are using." (underlining from the original, page IV-5 of The TUTOR Language, Sherwood, 1974.)

Functions could be defined, with macro-substitution semantics, as in this illustration from page IX-2 of The TUTOR Language, Sherwood, 1974:

define  cotan(a)=cos(a)/sin(a)

Unlike C, the original scope rules of TUTOR were pure "definition before use" with no provisions for local definitions. Thus, the formal parameter `a` used above must not have any previous definition.

Later in the development of TUTOR, with the introduction of multiple named sets of definitions, the programmer was given explicit control over which sets of definitions were currently in force. For example, `define purge, setname` would discard all definitions in the named set.[16]

#### Arrays, packed arrays, and text manipulation

The original TUTOR tools for text manipulation were based on commands for specific text operations, for example, `pack` to place a packed character string into consecutive variables in memory, `search` to search for one string within another, and `move` to move a string from memory to memory.[17] By 1975, more general tools for arrays of integers and packed arrays were added. Page 14 of PLATO User's Memo -- Summary of TUTOR Commands and System Variables, Avner, 1975, gives the following:

define  segment, name=starting var, num bits per byte, s
array, name(size)=starting var
array, name (num rows, num columns)=starting var

Segmented arrays, defined with the keyword `segment`, were comparable to packed arrays in Pascal. The byte size and whether or not the array elements were to be treated as signed or unsigned were entirely under user control. Arbitrary text manipulation could be done by setting the byte size to the machine byte size, 6 bits on implementations using display code, 8 bits on some later ASCII and extended ASCII implementations. Note the lack of any specification of array dimensionality for segmented arrays.

#### Parameter passing

A general parameter passing mechanism was added to TUTOR early in the PLATO IV era. Page IV-10 of The TUTOR Language by Sherwood, 1974 gives the following example:

define  radius=v1,x=v2,y=v3
unit    vary
do      halfcirc(100,150,300)
do      halfcirc(50)
unit    halfcirc(radius, x,y)
circle  radius, x,y,0,180
draw    x-radius, y;x+radius, y

Notice that the formal parameters listed in the argument list to the `unit` command are simply the defined names for statically allocated global variables. The semantics of parameter passing was given as being equivalent to assignment at the time of the control transfer to the destination unit, and if actual parameters were omitted, as in the second `do` command above, the effect was to leave the prior values of the corresponding formal parameters unchanged.

#### Local variables

Local variables were added to TUTOR some time around 1980. Lesson authors wishing to use local variables were required to use the `lvars` command to declare the size of the buffer used for local variables, up to 128 words.[18] Having done so, a unit using local variables could begin as follows (from Page C2 of Summary of TUTOR Commands and System Variables, Avner, 1981):

unit    someu
NAME1,NAME2,NAME3(SIZE)
NAME4=CONSTANT
floating:NAME5,NAME6,NAME7(SIZE)
integer, NUM BITS:NAME8,NAME9
integer, NUM BITS,signed:NAME10
integer:NAME11

The continuation lines of the `unit` command given above are taken to be lines of an implicit `define` command with local scope. Conventional definitions in terms of student variables such as `n150` could be used in such a local `define`, but the forms illustrated here all automatically bind names to locations in the block of memory allocated by the `lvars` command. The available TUTOR documentation does not discuss how local variables are allocated.

## Other implementations

There has been a sizable family of TUTOR-related languages, each similar to the original TUTOR language but with differences. In particular, TUTOR was a component of a system (the PLATO computer-based education system) that ran on particular CDC mainframe hardware. For efficiency, there were some hardware-specific elements in TUTOR (e.g. variables that were 60-bit words that could be used as arrays of 60 bits or as 10 six-bit characters, etc.). Also, TUTOR was designed before the advent of the windows-oriented graphical user interface (GUI).

The microTutor language was developed in the PLATO project at UIUC to permit portions of a lesson to run in terminals that contained microcomputers, with connections to TUTOR code running on the mainframe. The microTutor dialect was also the programming language of the Cluster system developed at UIUC and licensed to TDK in Japan; the Cluster system consisted of a small group of terminals attached to a minicomputer which provided storage and compilation. The Tencore Language Authoring System is a TUTOR derivative developed by Paul Tenczar for PCs and sold by Computer Teaching Corporation. cT was a derivative of TUTOR and microTutor developed at Carnegie Mellon which allowed programs to run without change in windowed GUI environments on Windows, Mac, and Unix/Linux systems.

## References

1. ↑ from page 4 of The TUTOR Language by Bruce Sherwood, 1974.
2. ↑ "Cyber1 PLATO Computer System". http://www.cyber1.org/.
3. ↑ Curtin, Constance; Clayton, Douglas; Finch, Cheryl; Moor, David; Woodruff, Lois (1972). "Teaching the Translation of Russian by Computer". The Modern Language Journal 56 (6): 354–60. doi:10.2307/324788. ISSN 1540-4781.
4. ↑ Forward progress with full backward compatibility by Bruce Sherwood, in the Python IDLE-dev Archives Apr. 9, 2000
5. ↑ Section 7.2 of Run-Time Support for the TUTOR Language on a Small Computer System, by Douglas W. Jones, 1976
6. ↑ see, for example, page 4-56 of the PLATO User's Guide, Control Data Corporation, 1981.
7. ↑ Tenczar and Golden, Spelling, Word and Concept Recognition, Computer-Based Education Research Laboratory Rep. X-35, University of Illinois at Urbana, 1972.
8. ↑ The Plato IV Student Terminal by Jack Stifle, Nov 1974
9. ↑ from page II-11 of The TUTOR Language by Bruce Sherwood, 1974.
10. ↑ see page II-9 of The TUTOR Language by Bruce Sherwood, 1974
11. ↑ from page II-3 of The TUTOR Language by Bruce Sherwood, 1974
12. ↑ See page IX-3 of The TUTOR Language by Sherwood, 1974
13. ↑ see Run Time Support of the TUTOR Language on a Small Computer System by Douglas W. Jones
14. ↑ see pages IV-2 and IX-17 of The TUTOR Language, Sherwood, 1974
15. ↑ see pages X-1 to X-3 and X-6 of The TUTOR Language, Sherwood, 1974
16. ↑ See page 15 of PLATO User's Memo -- Summary of TUTOR Commands and System Variables, Avner, 1975
17. ↑ Pages VII-52 to VII-55 of The TUTOR Language, Sherwood, 1974
18. ↑ Page C3 of Summary of TUTOR Commands and System Variables, Avner, 1981

## External links

* PLATO User's Guide, CDC Corporation, Revised April, 1981.
* TUTOR User's Memo. Introduction to TUTOR, Computer-Based Education Research Laboratory, University of Illinois at Urbana Champaign, March 1973.
* PLATO User's Memo, Number One: Summary of TUTOR Commands and System Variables. Third Edition, by Elaine Avner, Computer-Based Education Research Laboratory, University of Illinois at Urbana Champaign, November, 1975.
* Summary of TUTOR Commands and System Variables (10th edition), by Elaine Avner, Computer-Based Education Research Laboratory, University of Illinois at Urbana Champaign, November, 1981.
* A personal evaluation of the PLATO system bu Stewart A. Denenberg, ACM SIGCUE Outlook, 12, 2 (April 1978) pages 3–10.
* Run Time Support for the TUTOR Language on a Small Computer System, by Douglas W. Jones, 1976.
* The TUTOR Language, by Bruce Sherwood, Computer-Based Education Research Laboratory, University of Illinois at Urbana Champaign, June 1974.
* The TUTOR Language, by Bruce Sherwood, Control Data Education Company, 1977.
* The Plato IV Student Terminal, by Jack Stifle
* The cT Programming Language (derived from TUTOR) from Center for Design of Educational Computing at Carnegie Mellon University, by David Andersen, Bruce Sherwood, Judith Sherwood, and Kevin Whitley (no longer supported as of 2002).

0.00

(0 votes)

Original source: https://en.wikipedia.org/wiki/TUTOR. Read more

|

Retrieved from "https://handwiki.org/wiki/index.php?title=TUTOR&oldid=288390"