budd@arizona.UUCP (08/26/83)
First - regarding "what you see is what you get" text formatters vs
batch formatters - many of us are still restricted to ascii terminals,
or use phototypesetters with odd character sets, or print the same text
on various different devices with different characteristics. Thus I think
the batch mode type processing will be with us for a while. Thus while i
may agree that a nice bitmapped display connected to a laser printer or
something that permits "what you see..." is the wave of the future - many
people will be stuck in eddys for a while.
Second - you may recall that about a month ago i was discussing my ideas for
a revised troff. A two week vacation in the Northwest has permitted me to
cool off a bit (it is difficult to cool off in Tucson in the summer).
My analysis is as follows:
One reason [nt]roff (hereafter *roff) is so slow is that it is constantly
reinterpreting macros.
Macros are used for two distinct purposes in *roff. First, they are used by
document producers to simplify repetative tasks (I may have some fixed format
for figures, for example). Second, they are used by document format DESIGNERS
(ie, macro package writers) to define how a certain document is to be produced.
There are many different tools (eqn, M4) on UNIX that can be used to
accomplish the first task. Macros probably are not the right way to accomplish
the second task.
Now that I understand how to do dynamic loading (that is, loading routines
into an already executing program) I think macros for doing document
design should be abolished. Instead, the "routines" for doing document
layout should be written in C, and dynamically loaded in as required.
There are several advantages of this:
1. It is certainly true that no macro language I can create (and those
of you who have seen my previous posting may know I have created some
odd ones) can have as much "power" as C (ie, data structures, recursion,
system routines, etc etc).
2. Given an appropriate set of primitives (that is, other low level routines
that can be invoked) I don't think routines written in C would be any
more difficult to read/understand/produce than macro routines. In fact
they would probably be easier for most people to use, since most
programmers know C better than they know *roff (remember, we are only
talking about document database designers here, not your classic
naive user. The average user needs know nothing about how this is all
done).
3. Finally, having commands invoke C routines should make *roff a hell of a
lot faster. Perhaps even fast enough that a "what you see is what
you get" system can be created out of *roff, filters, pipes, masking
tape and bubble gum.
Comments?
--tim budd
{mcnc, teklabs, cornell, purdue, ucbvax, kpno} | arizona | budd