The Two Threads of Mathematical Computer Languages
Input for Computation
The question of how to input mathematical expressions, equations, and
formulas is as old as computers are. The first computers were built to
carry out scientific calculations, and early computer languages were
designed to simplify the process of translating mathematical formulas into
computer-interpretable form. The early language FORTRAN was even named
after this task: FORmula TRANslation.
Since input and output on early computers were limited to simple sequences
of letters (punch cards or teletypes, for example), it was natural to use a
simple linear syntax such as 1/(2+a**2) to represent
The fundamental notion behind these languages was to use the available simple
text editors (or card punches) to build up input expressions (programs)
one letter at a time. Then, when you were happy with your input, you would
submit it to the system, which parsed it according to the rules of the
language and created an internal representation in which unique
interpretations were assigned to each part of the expression (for example,
"power" as the interpretation assigned to a**2).
Input for Display and Printout
Almost as soon as computers had the capability, people started inventing
languages to allow them to create printed, typeset mathematical
expressions (along with typesetting the text around the expressions).
TeX was a system that became very popular with academic
users for writing research papers and books, and the SGML standard ISO
12083 was used by many publishers.
In these languages a linear text syntax is used to describe the
mathematical expression, and the intention is always to display or print
the expression and not to perform calculations with it. Because mathematical
typesetting involves only a very limited number of concepts (superscript,
subscript, vertical and horizontal stacking, a set of special letters, and
a few odd-ball notations like square roots), mathematical typesetting
languages can be fairly simple. The only real complexity comes about in
naming the large number of special symbols (Greek letters, Hebrew letters,
integral signs, etc).
Eventually, interactive graphical editors were created. These editors used palettes
and menus to allow the user to interactively construct typeset
expressions, which could then be saved in Tex or similar formats. Again the goal was always just
to format and not to compute.
Typeset Input for Computation
As computers became more powerful and graphical displays became common,
you might have expected some kind of convergence in which 2D typeset
mathematical expressions could be used as input for computational systems.
But by and large this did not happen. There were several systems for
creating and printing typeset mathematical expressions, and there were
several systems for doing mathematical calculations (numerical and
symbolic), but there were (and still are) remarkably few that combined 2D typeset input
One reason for this is that languages like TeX and ISO 12083, because they
were intended strictly for
typesetting, did not represent mathematical expressions in a particularly
mathematical way. For example, in TeX it is typical to represent the dx
portion of an integral such as:
as simply the characters "dx". It is very difficult for a computer system
to unambiguously differentiate between this being "differential operator
x" vs. "variable d times variable x" vs. "variable named dx".
These kinds of ambiguous, difficult-to-disentangle syntaxes pervade TeX
and ISO 12083, making them entirely unsuitable as
input languages for computer mathematics systems.
Another reason linear syntaxes remained the preferred form of entry for
computation was that early interactive 2D input systems were much more
cumbersome and time consuming to use than the linear syntaxes that they
might have replaced. Typing 1/(2+a**2) took much
less time than using the large palettes and confusing submenus of the
typical interactive 2D math input system. So users who were
interested just in getting calculations done didn't want to bother with typeset
input, and understandably so.
While there were several factors that made these typesetting systems
cumbersome, one of the most important was that they were fundamentally not
based on a parsing model. Instead of allowing the user to build up a
complex expression by assembling a small number of simple building blocks,
as linear syntaxes did, these systems essentially required the user to
assign the interpretations manually, choosing them from large palettes one
at a time.
The fixed template-based model of these typesetting systems also made
editing quite difficult because it did not allow intermediate states that
might not be valid input but that are very convenient ways of getting
from here to there in the editing process.
An analogy could be made between template vs. parsing-based systems and
pictographic vs. alphabetic written languages. An alphabetic language, in
which words are built up (parsed) out of a small number of letters,
allows for significantly more convenient input (by way of a suitably
sized keyboard) than do pictographic languages in which, roughly speaking,
each word is given a separate icon that must be selected from some kind of
palette. Without meaning any disrespect to the great and ancient cultures
whose languages are pictographic, the fact is that alphabets are faster
for computer input--and the same is true for mathematical expression
How to Get out of This Impasse
The solution to practical typeset input for computation was to combine the
simplicity of typesetting-oriented languages with a 2D parser that is able
to translate the essentially graphical description provided by the input
language into an expression that can be interpreted mathematically. It
turns out that this requires only a very small number of accommodations in
the form of disambiguating notations in the language. For example, it's
necessary to use a special "d" character for the differential
operator, rather than the ordinary "d" character that would be used as a
variable name. Consider:
Pity the poor computer system asked to interpret this if the two "d's" are
represented by the same character, as they would be in TeX, for example.
The realization that it actually was possible to use a simple, parsable
graphical syntax as input was the great, and to this day unique,
innovation of Mathematica's 2D math input system. Instead of large
complex palettes, a very small number of simple structural operations is
used to build up complex expressions, and free-form editing is allowed at
any stage. When it comes time to evaluate the expression, the system
parses the 2D structure using a comprehensive set of rules to assign
unique interpretations to all of the structures, just as is done when parsing
a linear syntax.
The Mathematica editing model, which is more like a text editor
than like other mathematical expression editors, allows efficient,
convenient input of expressions using no more keystrokes, and often fewer,
than linear syntaxes use. And the fact that typeset expressions in
Mathematica are represented by building up a small number of simple
"boxes" allows tremendous flexibility and extensibility without
The Origins of MathML
There was a danger during the 1990s that a standard would emerge for
mathematical representation on the web that would be based on a TeX-
or ISO 12083-like typesetting
language. This would have been disastrous because it would
have precluded, or made far more difficult, meaningful computational
interaction with mathematical expressions found on the web.
We felt that it was terrifically important that the user be able to copy/paste
a mathematical expression found anywhere on the web into a computer
mathematics system and have a reasonable expectation of being able to
evaluate it (say, make a plot of it, integrate it, etc). We also felt that
there was a significant danger of the standards evolving in a way that
would make this impossible.
To head off this possibility, Wolfram Research and Neil Soiffer decided to
do everything they could to encourage the creation of a practical standard
that would actually be used by web browser manufacturers and that would
preserve the possibility of evaluation in mathematical systems.
We realized that if a mathematical markup language were ever to be
supported by web browser manufacturers, and if it were ever to be practical
as a universal interchange format, it would have to be based on a very
simple set of fundamental constructs. If it were to be computable, it
would also have to incorporate the very set of disambiguating notations we had
developed for our own typesetting system. Finally, we knew that it had
taken many years of work by our top experts in the field to come up with a
really good way of unambiguously specifying mathematical notations using a
simple graphical syntax. We decided that we needed to use our experience
to guide the development of a standard that would work for the world.
And so, Neil Soiffer and Bruce Smith of Wolfram Research were founding
members of the drafting committee and creators of the original proposal
upon which MathML was based. The key ideas forming the core of the MathML
standard are derived directly from Wolfram Research's typesetting
The Committee Process
Taking a proposal from first draft to an accepted World Wide Web Consortium
(W3C) official recommendation is a
long and arduous task. From Soiffer's first draft to the current MathML 2
W3C Recommendation required about a dozen face-to-face meetings
and about two hundred teleconferences between the 15 to 20 committee
materials are available from the second conference, held in 2002.
The first official MathML conference, sponsored by Wolfram Research in October
2000, proved by its almost two hundred attendees that the effort to create a good
standard had been worthwhile.
Throughout the process Wolfram Research has been actively involved, always
with an eye to making sure that the standard remains usable and suitable for
automatic interpretation by computer mathematics systems.
As we see it, there are two fundament goals for the MathML standard: (1)
that web browser manufacturers find it practical to implement, or at least
support the implementation of, robust and well-integrated MathML renderers in
their browsers and (2) that the standard be one in which it is possible to
uniquely represent mathematical meaning in such a way that computer
programs can read, parse, and evaluate expressions represented in MathML
Only by achieving both of these goals can the MathML standard promote, rather than
hinder, the widespread presence on the internet of interpretable
mathematical expressions. We feel that through the work of Neil Soiffer
and others at Wolfram Research, the standard has achieved both goals