RFC 1019

Report of the Workshop on Environments for Computational Mathematics ✨

Okay bestie, this is RFC 1019 💅 It's a report from the Workshop on Environments for Computational Mathematics, written by D. Arnon of Xerox PARC. It's RFC number 1019, it's dated September 1987, and it's listed under the Network Working Group 🎀 The workshop itself happened on July 30, 1987, at the ACM SIGGRAPH Conference in the Anaheim Convention Center, Anaheim, California 🌈 The title block doesn't list a category, and it doesn't say it obsoletes or updates anything, so I'm not gonna make that up 🙈

---

Status of This Memo 📜

So this memo is a report on the discussion of how equations get represented at a workshop during the ACM SIGGRAPH Conference in Anaheim, California, on 30 July 1987 🦋 Distribution of this memo is unlimited, so share it with everyone 💜

Introduction 🌸

Okay so the dream of natural, powerful computer systems for doing math interactively has been around since the 1950s 🧚 Nowadays that dream sounds like one integrated system for symbolic, numerical, graphical, and documentational math work, and it's giving main character energy ✨ Personal computers with high-resolution screens, window systems, and mice, plus high-speed networks, electronic mail, and electronic publishing, have basically built a foundation that's more than enough to make this happen 🔥 The problem is that the Mathematical Typesetting, Multimedia Electronic Mail, Numerical Computation, and Computer Algebra communities are all growing separately, each with its own conventions, and that could literally stop these systems from getting built 💀

Here's the tea 🫖 Not much thought has gone into unifying the different ways of representing expressions that each community uses, and that has to happen if math expressions are gonna be interchanged between Document, Display, and Computation systems 😭 Also, tools that several communities want, like WYSIWYG mathematical expression editors, are getting built by each group on its own, with barely any awareness of how much duplicated effort that creates 🙃 Worst of all, the huge chances for communities to cross-fertilize aren't being used at all 🥀 For example, some Computer Algebra systems explicitly attach a type to a math expression (like a 3 x 3 matrix of polynomials with complex number coefficients), and that could enable automated math proofreaders, kind of like spelling checkers 🤯

The goal of the Workshop on Environments for Computational Mathematics was to get representatives of the Computer Algebra, Numerical Computation, Multimedia Electronic Mail, and Mathematical Typesetting communities talking to each other 💬 Back in July 1986, during the Computers and Mathematics Conference at Stanford University, a subset of this year's participants met at Xerox PARC to talk about User Interfaces for Computer Algebra Systems 🎀 That group agreed to keep meeting in the future, and this Workshop is the first of those meetings 🌟 Alan Katz's recent essay, "Issues in Defining an Equations Representation Standard", RFC-1003, DDN Network Information Center, March 1987 (reprinted in the ACM SIGSAM Bulletin May 1987, pp. 19-24), shaped the discussion at the Workshop, especially since it talks about interchanging mathematical expressions 📚

This report isn't a transcript of the Workshop, lowkey not even close 🙅‍♀️ Instead it tries to pull out the major points where, in the Editor's view, there was rough consensus 🫶 The Editor thinks the Workshop discussion can be summed up as a basic architecture for "Standard Mathematical Systems", which shows up in Section II below ✨ Meeting participants seemed to agree on two things: (1) existing mathematical systems should be augmented or modified to conform to this architecture, and (2) future systems should be built in accordance with it 🔥

The Talks and Panel-Audience discussions at the Workshop were videotaped 🎥 Those tapes are being edited for submission to the SIGGRAPH Video Review, to form a "Video Proceedings" 🍓 If SIGGRAPH accepts them, the Video Proceedings will be publicly available for a nominal distribution charge 🌈

One big thing the Workshop explicitly left out is "intelligence" in mathematical systems 🧠 This has been a powerful motivation for systems builders since the early days, but even though it matters, nobody expects intelligent behavior in mathematical systems to happen in the short term, so it got set aside 🙈 Computer Assisted Instruction for mathematics was also outside the scope of the Workshop 📖 And even though it might've been a good idea to invite people from the Spreadsheets and Graphics communities, they weren't invited 🥺 That said, many of the people who were there have thought a lot about Spreadsheets and Graphics in mathematical systems 💜

Huge thanks to Xerox Corporation for the financial support for AudioVisual equipment rental at SIGGRAPH 🫶 Thanks also to Kevin McIsaac, who served as chief cameraman, gave critical comments on this report, and helped out with the Workshop in lots of other ways 📸 Thanks to Richard Fateman, Michael Spivak, and Neil Soiffer too, for their critical comments on this report 🎀 And Subhana Menis and Erin Foley helped with logistics and documentation at several points along the way 🧚

If you want information on the Video Proceedings or any other part of the Workshop, you can get it from the author of this report 💌

I. Particulars of the meeting 🎀

The Workshop had four parts: (1) Talks, (2) Panel Discussion, (3) Panel and Audience discussion, and (4) Live demos 🌸 Only a few of the systems presented in the talks were demonstrated live, but lots of the talks included videotapes of the systems being discussed 📼

The talks, each 15 minutes long, were:

1. "The MathCad System: a Graphical Interface for Computer Mathematics", Richard Smaby, MathSOFT Inc. ✨
2. "MATLAB - an Interactive Matrix Laboratory", Cleve Moler, MathWorks Inc. 🌈
3. "Milo: A Macintosh System for Students", Ron Avitzur, Free Lance Developer, Palo Alto, CA. 🍎
4. "MathScribe: A User Interface for Computer Algebra systems", Neil Soiffer, Tektronix Labs. 💅
5. "INFOR: an Interactive WYSIWYG System for Technical Text", William Schelter, University of Texas. 🦋
6. "Iris User Interface for Computer Algebra Systems", Benton Leong, University of Waterloo. 🌷
7. "CaminoReal: A Direct Manipulation Style User Interface for Mathematical Software", Dennis Arnon, Xerox PARC. 👑
8. "Domain-Driven Expression Display in Scratchpad II", Stephen Watt, IBM Yorktown Heights. 🔥
9. "Internal and External Representations of Valid Mathematical Reasoning", Tryg Ager, Stanford University. 🧠
10. "Presentation and Interchange of Mathematical Expressions in the Andrew System", Maria Wadlow, Carnegie-Mellon University. 💜

The Panel discussion lasted 45 minutes 🎤 The panelists were:

• Richard Fateman, University of California at Berkeley 🫶
• Richard Jenks, IBM Yorktown Heights 💖
• Michael Spivak, Personal TeX ✨
• Ronald Whitney, American Mathematical Society 🌸

The panelists were asked to think about these issues when planning their presentations 🧩

1. Should we try to build integrated documentation/computation systems? 🤔
2. WYSIWYG editing of mathematical expressions. 🖊️
3. Interchange representation of mathematics. 🔁
4. User interface design for integrated documentation/computation systems. 🎨
5. Coping with large mathematical expressions. 🐘

The Panel-Audience discussion lasted another 45 minutes, and the Demos lasted about one hour 🎬

Other Workshop participants, besides the ones named above, included:

• S. Kamal Abdali, Tektronix Labs 🌟
• George Allen, Design Science 🦋
• Alan Katz, Information Sciences Institute 📚
• J. Robert Cooke, Cornell University and Cooke Publications 🍓
• Larry Lesser, Inference Corporation 🌈
• Tom Libert, University of Michigan 🎀
• Kevin McIsaac, Xerox PARC and University of Western Australia 📸
• Elizabeth Ralston, Inference Corporation 💜

II. Standard Mathematical Systems - a Proposed Architecture ✨

okay so the core idea is that there's an "Abstract Syntax" for ANY mathematical expression 🧮💖. Every piece of it is an Operator plus an (ordered) list of Arguments, and each Argument is its own piece of Abstract Syntax, so it nests all the way down 🪆. Functional Notation, Lisp SExpressions, Directed Acyclic Graphs, and N-ary Trees are all equivalent ways to write this. They're equally expressive, though one might be nicer for computation and algorithms 🧠. For example, Plus[Times[a,b],c] is the Abstract Syntax for what everybody writes as a*b+c 🎀.

A "Standard Mathematical Component" (SMC for short) is a bunch of software and hardware modules that do ONE job 💅. If it reads math, it reads Abstract Syntax. If it writes math, it writes Abstract Syntax. An "Standard Mathematical System" (SMS) is a group of SMCs that work together and talk to each other in Abstract Syntax 🫶.

We identify at least four possible component types in an SMS. Literally the minimum, not the maximum 👑.

Any particular SMS can have zero, one, or several instances of each component type. The connection between two components in an SMS, whatever their type, is Abstract Syntax passed over a "wire" joining them 🔌.

1) EDs - Math Editors 🖊️

These edit Abstract Syntax into Abstract Syntax. A system can have editors that work on other representations of math (bitmaps, or particular formatting languages, for example), but those don't count as ED components of an SMS 🙈. An ED can be WYSIWYG or language-oriented, your choice 💖.

2) DISPs - Math Displayers 🖨️

These are suites of software packages, device drivers, and hardware devices that take in an expression in Abstract Syntax and render it. For example, (1) the combo of an Abstract Syntax->TeX translator, TeX itself, and a printer, or (2) a plotting package plus a plotting device ✨. A DISP may or may not support "pointing" (aka selection) within an expression it has displayed. A printer probably doesn't, but a terminal screen might 🖥️. If pointing IS supported, then a DISP must be able to pass the selected subexpression(s) back in Abstract Syntax. We're not trying to predict or limit what selection mechanisms different DISPs offer here. We only require that a DISP can communicate its selections in Abstract Syntax 🦋.

3) COMPs - Computation Systems 🧮

Examples are Numerical Libraries and Computer Algebra systems. There are open questions about the state a COMP is in when it receives an expression. For example, which global flags are set, or which previous expressions have been computed that the current one might refer to 🤔. We're not going to dive into those hard issues yet though 🙈.

4) DOCs - Document Systems 📝

These are what people would typically call "text editors", "document editors", or "electronic mail systems". We care about how they handle math expressions 💜. In reality they manage other document constituents too (text and graphics, for example), and designing a UI for math, text, and graphics together is a nontrivial problem that will DEFINITELY be the subject of more research 😭.

A typical SMS will have an ED and a DISP that are way more closely coupled than this makes it sound 🫂. For example, the ED's internal representation of Abstract Syntax and the DISP's internal representation (like a tree of boxes) might have pointers going back and forth, or even share a common data structure. That's acceptable! But it should ALWAYS be possible to access the two components in the canonical, decoupled way 🔐. For example, the ED should be able to receive a standard Abstract Syntax representation of an expression, plus an editing command in Abstract Syntax (like Edit[expr, cmd]), and return an Abstract Syntax representation of the result. Similarly, the DISP should be able to receive Abstract Syntax over the wire and display it. If it supports pointing, it should be able to return selected subexpressions in Abstract Syntax too 💅.

The boundaries between component types are not hard and fast, so don't panic if things blur 🌈. For example, an ED might support simple computations (simplification, rearranging subexpressions, arithmetic), or a DOC might have a facility for displaying math expressions. The key thing for a module to qualify as an SMC is its ability to read and write Abstract Syntax. That's it, that's the whole vibe 🎀✨.

III. Recommendations and Qualifications 💖

1. It's our hypothesis that it will be feasible to encode a rich variety of other languages in Abstract Syntax, programming constructs for example 🧠. So we intend it to be possible to pass things like Lisp formatting programs, plot programs, TeX macros, etc. over the wire in Abstract Syntax 🦋. We also hypothesize that it will be possible to encode all present and future mathematical notations in Abstract Syntax (commutative diagrams in two or three dimensions, for example) 🌸. For example, the 3 x 3 identify matrix might be encoded as:

Matrix[ [1,0,0], [0,1,0], [0,0,1] ]

while the Abstract Syntax expression:

Matrix[5, 5, DiagonalRow[1, ThreeDots[], 1],
BelowDiagonalTriangle[FlexZero[]],
AboveDiagonalTriangle[FlexZero[]]]

might encode a 5 x 5 matrix that's displayed with a "1" in the (1,1) position, a "1" in the (5,5) position, three dots between them on the diagonal, a big fat zero in the lower triangle indicating the presence of zeros there, and a big fat zero in the upper triangle indicating zeros too 😭🍓.

2. We assume the use of the ASCII character set for Abstract Syntax expressions 🔤. Greek letters, for example, would need to be encoded with expressions like Greek[alpha], or Alpha[]. Font encoding works the same way. Here's the Abstract Syntax for 12pt bold Times Roman: Font[timesRoman, 12, bold, <expression>] 💅. Two SMCs are free to communicate in a larger character set, or to pass font specifications in other ways. But they should always be able to express themselves in standard Abstract Syntax as well 🫶.
3. COMPs (Computer Algebra systems, for example) should be able to communicate in Abstract Syntax 🧮. Existing systems should get translators to and from Abstract Syntax added to them 🛠️. And here's the big payoff: if we can establish a collection of standard names and argument lists for common functions, and get all COMPs to read and write them, then ANY Computer Algebra system can talk to ANY other one 👑😭. Some examples of possible standard names and argument lists for common functions:

Plus[a,b,...]
Minus[a]
Minus[a,b]
Times[a,b,...]
Divide[<numerator>, <denominator>]
Power[<base>, <exponent>]
PartialDerivative[<expr>, <var>]
Integral[<expr>, <var>, <lowerLimit>,<upperLimit>] (limits optional)
Summation[<<summand>, <lowerLimit>, <upperLimit>] (limits optional)

A particular algebra system may read and write nonstandard Abstract Syntax too. For example:

Polynomial[Variables[x, y, z], List[Term[coeff, xExp, yExp, zExp],
...

but it should be able to translate this into an equivalent standard representation. For example:

Plus[Times[coeff, Power[x, xExp], ...

4. A DOC must store the Abstract Syntax representations of the expressions it contains 📚. That makes it easy to pass those expressions to EDs, COMPs, or DISPs 💌. A DOC is free to store additional expression representations too, like a tree of Boxes, a bitmap, or a TeX description 🎨.
5. DISPs will typically have local databases of formatting information 🗂️. To actually render Abstract Syntax, the DISP checks its database for display rules. If it finds none, it paints the Abstract Syntax in some standard way. Local formatting databases can be overridden by formatting rules passed over the wire, written in Abstract Syntax. Formatting databases are where knowledge of particular display environments lives (like "typesetting for Journal X") 📰.

The paradigm we want to follow is the genetic code 🧬. A mathematical expression is like a particular instance of DNA. When a DISP receives it, the DISP consults the appropriate formatting database to see if it understands it. If not, the DISP just "passed it through unchanged" 🤷‍♀️. The expression sent over the wire may come with directives or explanatory information, which again may or may not mean anything to a particular DISP 🧚. In reality, formatting databases may need Expert System-level sophistication to produce professional quality typesetting results. But we believe useful results can be achieved even without that level of sophistication ✨.

6. Because of the SMCs specified above, it becomes easy to use any DOC as a logging facility for a session with a COMP 🪵. So improvements in DOCs (browsers, level structuring, active documents, audit trails, etc.) will automatically give us better logging mechanisms for sessions with algebra systems 🙌.
7. Note that Abstract Syntax is human-readable 👀. So any text editor can be used as an ED 💻. Of course, in a typical SMS, users shouldn't need to look at the Abstract Syntax flowing through the internal "wires" if they don't care to 🙈. Many people will want to interact only with mathematics that has a textbook-like appearance, and they should be able to do exactly that 📖💖.
8. Alan Katz's RFC (cited above) distinguishes the form (appearance) of a mathematical expression from its content (meaning, value). We DON'T agree that such a distinction can be made 🙅‍♀️. We claim that Abstract Syntax can convey form, meaning, or both, and that its interpretation is strictly in the eye of the beholder(s) 👁️. Meaning is just a handshake between sender and recipient 🤝.
9. Help and status queries, the replies to help and status queries, and error messages should be read and written by SMCs in Abstract Syntax 🆘.
10. In general, it's permissible for two SMCs to use private protocols for communication 🔒. Our tightly coupled ED and DISP example above is one case of this. Two instances of a Macsyma COMP would be another. They might agree to pass Macsyma internal representations back and forth 🧠. But to qualify as SMCs, they should be able to translate all such exchanges into equivalent exchanges in Abstract Syntax 🫶🌈.