home *** CD-ROM | disk | FTP | other *** search
/ minnie.tuhs.org / unixen.tar / unixen / PDP-11 / Trees / V7 / usr / doc / eqn / e3 < prev    next >
Encoding:
Text File  |  1979-01-10  |  4.5 KB  |  133 lines
  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.
  133.