Re: [Groff] Lack of professionalism ....

[Doug McIlroy]

> 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