M4 macro processor

[Martin Weitzel]

In article <873 at fnx.UUCP> del at fnx.UUCP (Dag Erik Lindberg) writes:
>I have an application that is just screaming for something like a 
>macro-processor.  The C pre-processor is no good because the files
>I need to deal with are Motorola assembly sources which use '#'
>to signify a constant value as opposed to a memory reference.

The C-Preprocessor is a C-Preprocessor is a C-Preprocessor ....
and NOT a general macro processor. I support your view so far.

>The M4 macro processor sounds like it might work, and is available
>on both the ISC and SCO systems I have access to, but the manuals
>only seem to include information on how to run the program, and the
>pre-defined macros.

Try to get your hands on Part 1 of the good ol' UPM (UNIX Programmers
Manual - I hope I remember this right and it wasn't Part 2). You'll
find numereous nice tutorials on some of the more complex tools, not
only (but of course also) for M4.

ifelse(sidenotes,`yes',`

It's a pitty that later software companies who did the various UNIX
ports didn't understand the organization of the two parts of the UPM,
especially that these two parts build a unit: The "reference entries"
were arbitrarily split off and much background information vanished
with this. There is more than one case were you can prove that the
man page is incomplete (i.e. some features are only described half
and some parts are obviously missing). But those incomplete docs
made it even into SVID and XPG3.

Only some few vendors gave the tutorials a chance to survive. (I just
checked this for XENIX 286, which did.) In case of doubt have a look
for the "Programmers Guide" - maybe you find some of the old stuff there.

')	dnl (you'll understand this one day :-))

>There is nothing on how to write macros for the
>thing.
>
>Any pointers?

Of course: (You can try the following interactively if you call
M4 without arguments, but every small sections should be tried
independently, i.e. I've not designed this to take care of the
earlier definitions.)

	define(a,b)
	a	-----> prints: b

In most cases (and especially for macros) it is important that macro
replacement takes place very early, i.e. if you do the following

	define(x,y)
	define(x,z)

you don't re-define the macro x in the second case but rather define
a macro y, since the x is replaced by y in the second define before
the definition is stored. Because of that it is generally advisable
to quote things you mean "literally", e.g

	define(`x',y)
	define(`x',z)

which would set up two definitions of x, with the replacement text
y and z, provided the latter two have not been previously be defined as
macros (in the latter case their replacement would take place prior to
storing the definition, but this could easily be overlooked by the
fact that even if it weren't there would occur a replacement during
expansion of macro x. You can also stack macro definitions with
pushdef and pop them with popdef, but again be aware

	pushdef(x,y)
	popdef(x)

would try to pop the definition of the macro y, not x (replacement is
done early, no implicit quoting during argument scan!). As this draws
no complaint you may at first think popdef (or undefine) doesn't work,
but usually there are just some quotes missing. The qouting mechanism
uses the (balanced) delimiters ` and ' and one level of quotes is stripped
during the primary scan of the input and an additional level with
every macro expansion. I warned you, it can become a little complex
(sometimes you'll get knots in your brains, as we would express it in
German) and I've typed this all out of my brain, which may still be a
little knotted from extensively using M4 about three years ago :-)

No, what I really wanted to say is: I've checked the above information
quickly during writing this article, but I may remember some things
wrong and have not checked thoroughly enough here. In case of doubt:
Try all this by yourself with small experiments.

Well, that will not be sufficient for real sophisticated work, but
may be a start. Getting the quoting right can be tricky sometimes,
but in general M4 is very consistent, i.e. you only need to know a
few rules to work with it. If you have any questions feel free to
send me mail, but don't expect a quick answer (I've no access to my
system in the next two weeks).
-- 
Martin Weitzel, email: martin at mwtech.UUCP, voice: 49-(0)6151-6 56 83