The fundamental principle upon which we based our language design
is that the language should be easy to use
by people (for example, secretaries) who know neither mathematics nor typesetting.
``normal'' mathematical conventions about operator precedence,
parentheses, and the like cannot be used,
for to give special meaning to such characters means
that the user has to understand what he or she
Thus the language should not assume, for instance,
that parentheses are always balanced,
the half-open interval $(a,b]$.
Nor should it assume that
that $sqrt{a+b}$ can be replaced by
or that $1/(1-x)$ is better written as $1 over 1-x$
Second, there should be relatively few rules,
special symbols and operators, and the like.
This keeps the language easy to learn and remember. Furthermore, there should be few exceptions to
if something works in one situation,
it should work everywhere.
If a variable can have a subscript,
then a subscript can have a subscript, and so on without limit.
Third, ``standard'' things should happen automatically.
Someone who types ``x=y+z+1'' should get ``$x=y+z+1$''.
Subscripts and superscripts should automatically
be printed in an appropriately smaller size,
with no special intervention.
Fraction bars have to be made the right length and positioned at the
Indeed a mechanism for overriding default actions has to exist,
but its application is the exception, not the rule.
that the typist has a reasonable picture
(a two-dimensional representation)
of the desired final form, as might be handwritten
by the author of a paper.
the input is typed on a computer terminal much like an ordinary typewriter.
This implies an input alphabet
of perhaps 100 characters,
A secondary, but still important, goal in our design
was that the system should be easy to implement,
since neither of the authors had any desire to make
a long-term project of it.
Since our design was not firm,
it was also necessary that the program be easy to change
To make the program easy to build and to change,
and to guarantee regularity
(``it should work everywhere''),
the language is defined by a
context-free grammar, described in Section 5.
The compiler for the language was built using a compiler-compiler.
the grammar/compiler-compiler approach seemed the right thing to do.
Our subsequent experience leads us to believe
that any other course would have been folly.
The original language was designed in a few days.
Construction of a working system
sufficient to try significant examples
required perhaps a person-month.
Since then, we have spent a modest amount of additional time
tuning, adding facilities,
and occasionally changing the language as users
make criticisms and suggestions.
We also decided quite early that
do our work for us whenever possible.
is quite a powerful program, with
a macro facility, text and arithmetic variables, numerical computation and testing,
and conditional branching.
Thus we have been able to avoid writing
a lot of mundane but tricky software.
For example, we store no text strings,
but simply pass them on to
Thus we avoid having to write a storage management package.
Furthermore, we have been able to isolate ourselves
from most details of the particular device and character set
compute the widths of all strings of characters;
we need know nothing about them.
A third design goal is special to our environment.
Since our program is only useful for typesetting mathematics,
it is necessary that it interface cleanly with the underlying typesetting language
who want to set intermingled mathematics and text
The standard mode of operation
is that when a document is typed,
mathematical expressions are input as part of the text,
but marked by user settable delimiters.
The program reads this input and treats as comments
those things which are not mathematics,
simply passing them through untouched.
At the same time it converts the mathematical input
The resulting ioutput is passed directly to
where the comments and the mathematical parts both become