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: answer (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: wrong 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. 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. 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: if n86 . . write special branch . endif endif (The
assignment arrow in the calc statement is not rendered correctly in some browsers. It appears similar to loop, endloop blocks with semantics comparable to
while loops in conventional programming languages. This is illustrated in the following example loop n8 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 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. 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.
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.
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. 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). 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 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: 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." Functions could be defined, with macro-substitution semantics, as in this illustration: 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.
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. By 1975, more general tools for arrays of integers and packed arrays were added. For example: 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. For 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. Having done so, a unit using local variables could begin as follows: 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==