> And, perhaps most important: It makes execution slower! Contrary to > TeX, groff doesn't have an internal representation form of macros. > This means that a macro gets interpreted exactly as written. For > example, if a macro that contains a line to call a request has 100 > spaces after the leading dot, the 100 spaces are interpreted again and > again if you execute the macro. Consequently, `make install' strips > (almost) all spaces from the mdoc macro files before they get > installed. Similarly, the `doc-' prefix gets removed to make the > commands shorter.
I was surprised to learn that distributed macro packages aren't the "real thing", but only shadows left by a complex build process. The given reason was unpersuasive, so I ran an experiment. I made a copy of s.tmac with 10 spaces after each initial dot. Then I ran groff on a 25,000-line source file which includes 8,000 request lines, essentially all -ms macros. User times with and without extra space were indistinguishable to three significant digits: any difference was swamped out by timing noise. So it looks to me as if the policy of distributing mildly compressed macro packages has only two perceptible effects: it complicates maintenance and it complicates understanding. I am thus led to believe that this is yet another instance of ungainly galloping gnus departing from Unix's original path of simplicity and transparency. Doug
