Download FWEB manual - (La)TeX Navigator

48
— Outer macros —
macros”. These are defined by the command ‘@d’, which is allowed in the definition section only. WEB does
not expand these; rather, it just collects them and copies them at the start of phase two to the beginning of
the output file in a format appropriate for the relevant language compiler. For symmetry, the command ‘@u’
is also provided to undefine an outer macro.
The format of outer macros depends on the language in force. If the current language is C, the outer
macros should, of course, be in the format appropriate to the C preprocessor; an outer C definition of the
form ‘@d A 1’ will appear in the beginning of the C output file as ‘#define A 1’. Otherwise, the outer
macro should be in the format appropriate to the m4 preprocessor. In languages other than C, the definition
‘@d (B,2)’ will appear in the beginning of the output file as ‘define(B,2)’. (With the advent of FWEB’s
macro processor, the need for outer macro definitions in languages other than C should virtually disappear.)
For example, when the language is C, the statements
@
@d A 1
@d B 2
@
@u A
@d A 2
will be output as follows:
#define A 1
#define B 2
#undef A
#define A 2
A C program maintained with WEB should almost exclusively contain the outer macro, ‘@d’ commands.
The internal, ‘@m’ commands should be used only when the WEB system provides a macro feature not included
in the C preprocessor. Those features mostly include stringizing and token pasting (included in the ANSI
C standard, but not in many extant compilers). If you are using an ANSI C compiler, your need for WEB
macros will be slight, although a few of the extensions such as #! or variable arguments may prove useful.
♣ 7.3 Deferred macros
Returning now to the internal WEB macros, their order of evaluation requires further discussion. It
is important to understand that all text, including macro definitions, is collected, tokenized, and stored
during TANGLE’s phase one. However, with certain exceptions (involving the preprocessor) to be described,
no macros are actually expanded during phase one. The reason for this is that the actual source text in
which the macros are embedded and on which they must operate is not known until all the text has been
collected and placed into the proper modules. Therefore, it is during phase two, when the completed code
text is output, that macros are expanded. However, in the original design of WEB this led to an annoying
difficulty—namely, WEB macro definitions could be retroactive.
The situation arises as follows. In the original design, macros were allowed only in the definition section
of a module. Since all such macros definitions are collected during phase one, they are all known by the
time code is output during phase two. (Effectively, they are all placed at the top of the unnamed module.)
Thus, a definition made in the definition section of, say, module 100 could lead to a macro being expanded
in module 1 if the code in module 1 contained a reference to that macro name. Although this is usually the
desired effect, it may not be in all cases. Consider, for example, the following example (see the discussion of
preprocessor commands, below):
@ Here is a peculiar example of retroactive macro definition.