home *** CD-ROM | disk | FTP | other *** search
/ The Datafile PD-CD 4 / DATAFILE_PDCD4.iso / unix / riscbsd / 1_1_contri / usd / 26_eqn / e3 < prev    next >
Encoding:
Text File  |  1986-05-22  |  4.5 KB  |  135 lines
  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.
  135.