Commit | Line | Data |
---|---|---|
8340f87c BJ |
1 | .NH |
2 | Language Design | |
3 | .PP | |
4 | The fundamental principle upon which we based our language design | |
5 | is that the language should be easy to use | |
6 | by people (for example, secretaries) who know neither mathematics nor typesetting. | |
7 | .PP | |
8 | This principle implies | |
9 | several things. | |
10 | First, | |
11 | ``normal'' mathematical conventions about operator precedence, | |
12 | parentheses, and the like cannot be used, | |
13 | for to give special meaning to such characters means | |
14 | that the user has to understand what he or she | |
15 | is typing. | |
16 | Thus the language should not assume, for instance, | |
17 | that parentheses are always balanced, | |
18 | for they are not in | |
19 | the half-open interval $(a,b]$. | |
20 | Nor should it assume that | |
21 | that $sqrt{a+b}$ can be replaced by | |
22 | $(a+b) sup roman \(12$, | |
23 | or that $1/(1-x)$ is better written as $1 over 1-x$ | |
24 | (or | |
25 | vice versa). | |
26 | .PP | |
27 | Second, there should be relatively few rules, | |
28 | keywords, | |
29 | special symbols and operators, and the like. | |
30 | This keeps the language easy to learn and remember. Furthermore, there should be few exceptions to | |
31 | the rules that do exist: | |
32 | if something works in one situation, | |
33 | it should work everywhere. | |
34 | If a variable can have a subscript, | |
35 | then a subscript can have a subscript, and so on without limit. | |
36 | .PP | |
37 | Third, ``standard'' things should happen automatically. | |
38 | Someone who types ``x=y+z+1'' should get ``$x=y+z+1$''. | |
39 | Subscripts and superscripts should automatically | |
40 | be printed in an appropriately smaller size, | |
41 | with no special intervention. | |
42 | Fraction bars have to be made the right length and positioned at the | |
43 | right height. | |
44 | And so on. | |
45 | Indeed a mechanism for overriding default actions has to exist, | |
46 | but its application is the exception, not the rule. | |
47 | .PP | |
48 | We assume | |
49 | that the typist has a reasonable picture | |
50 | (a two-dimensional representation) | |
51 | of the desired final form, as might be handwritten | |
52 | by the author of a paper. | |
53 | We also assume that | |
54 | the input is typed on a computer terminal much like an ordinary typewriter. | |
55 | This implies an input alphabet | |
56 | of perhaps 100 characters, | |
57 | none of them special. | |
58 | .PP | |
59 | A secondary, but still important, goal in our design | |
60 | was that the system should be easy to implement, | |
61 | since neither of the authors had any desire to make | |
62 | a long-term project of it. | |
63 | Since our design was not firm, | |
64 | it was also necessary that the program be easy to change | |
65 | at any time. | |
66 | .PP | |
67 | To make the program easy to build and to change, | |
68 | and to guarantee regularity | |
69 | (``it should work everywhere''), | |
70 | the language is defined by a | |
71 | context-free grammar, described in Section 5. | |
72 | The compiler for the language was built using a compiler-compiler. | |
73 | .PP | |
74 | A priori, | |
75 | the grammar/compiler-compiler approach seemed the right thing to do. | |
76 | Our subsequent experience leads us to believe | |
77 | that any other course would have been folly. | |
78 | The original language was designed in a few days. | |
79 | Construction of a working system | |
80 | sufficient to try significant examples | |
81 | required perhaps a person-month. | |
82 | Since then, we have spent a modest amount of additional time | |
83 | over several years | |
84 | tuning, adding facilities, | |
85 | and occasionally changing the language as users | |
86 | make criticisms and suggestions. | |
87 | .PP | |
88 | We also decided quite early that | |
89 | we would let | |
90 | .UC TROFF | |
91 | do our work for us whenever possible. | |
92 | .UC TROFF | |
93 | is quite a powerful program, with | |
94 | a macro facility, text and arithmetic variables, numerical computation and testing, | |
95 | and conditional branching. | |
96 | Thus we have been able to avoid writing | |
97 | a lot of mundane but tricky software. | |
98 | For example, we store no text strings, | |
99 | but simply pass them on to | |
100 | .UC TROFF . | |
101 | Thus we avoid having to write a storage management package. | |
102 | Furthermore, we have been able to isolate ourselves | |
103 | from most details of the particular device and character set | |
104 | currently in use. | |
105 | For example, we let | |
106 | .UC TROFF | |
107 | compute the widths of all strings of characters; | |
108 | we need know nothing about them. | |
109 | .PP | |
110 | A third design goal is special to our environment. | |
111 | Since our program is only useful for typesetting mathematics, | |
112 | it is necessary that it interface cleanly with the underlying typesetting language | |
113 | for the benefit of users | |
114 | who want to set intermingled mathematics and text | |
115 | (the usual case). | |
116 | The standard mode of operation | |
117 | is that when a document is typed, | |
118 | mathematical expressions are input as part of the text, | |
119 | but marked by user settable delimiters. | |
120 | The program reads this input and treats as comments | |
121 | those things which are not mathematics, | |
122 | simply passing them through untouched. | |
123 | At the same time it converts the mathematical input | |
124 | into the necessary | |
125 | .UC TROFF | |
126 | commands. | |
127 | The resulting ioutput is passed directly to | |
128 | .UC TROFF | |
129 | where the comments and the mathematical parts both become | |
130 | text and/or | |
131 | .UC TROFF | |
132 | commands. |