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