[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This chapter covers macro invocation, macro arguments and how macro expansion is treated.
3.1 Macro invocation 3.2 Preventing macro invocation 3.3 Macro arguments 3.4 Quoting macro arguments On Quoting Arguments to macros 3.5 Macro expansion Expanding macros
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Macro invocations has one of the forms
name |
which is a macro invocation without any arguments, or
name(arg1, arg2, ..., argn) |
which is a macro invocation with n arguments. Macros can have any number of arguments. All arguments are strings, but different macros might interpret the arguments in different ways.
The opening parenthesis must follow the name directly, with no spaces in between. If it does not, the macro is called with no arguments at all.
For a macro call to have no arguments, the parentheses must be left out. The macro call
name() |
is a macro call with one argument, which is the empty string, not a call with no arguments.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
An innovation of the m4
language, compared to some of its
predecessors (like Stratchey's GPM
, for example), is the ability
to recognize macro calls without resorting to any special, prefixed
invocation character. While generally useful, this feature might
sometimes be the source of spurious, unwanted macro calls. So, GNU
m4
offers several mechanisms or techniques for inhibiting the
recognition of names as macro calls.
First of all, many builtin macros cannot meaningfully be called without arguments. For any of these macros, whenever an opening parenthesis does not immediately follow their name, the builtin macro call is not triggered. This solves the most usual cases, like for `include' or `eval'. Later in this document, the sentence "This macro is recognized only when given arguments" refers to this specific provision.
There is also a command call option (--prefix-builtins
, or
-P
) which requires all builtin macro names to be prefixed
by `m4_' for them to be recognized. The option has no effect
whatsoever on user defined macros. For example, with this option,
one has to write m4_dnl
and even m4_m4exit
.
If your version of GNU m4
has the changeword
feature
compiled in, there it offers far more flexibility in specifying the
syntax of macro names, both builtin or user-defined. See section 7.4 Changing the lexical structure of words
for more information on this experimental feature.
Of course, the simplest way to prevent a name to be interpreted as a call to an existing macro is to quote it. The remainder of this section studies a little more deeply how quoting affects macro invocation, and how quoting can be used to inhibit macro invocation.
Even if quoting is usually done over the whole macro name, it can also be done over only a few characters of this name. It is also possible to quote the empty string, but this works only inside the name. For example:
`divert' `d'ivert di`ver't div`'ert |
all yield the string `divert'. While in both:
`'divert divert`' |
the divert
builtin macro will be called.
The output of macro evaluations is always rescanned. The following
example would yield the string `de', exactly as if m4
has been given `substr(abcde, 3, 2)' as input:
define(`x', `substr(ab') define(`y', `cde, 3, 2)') x`'y |
Unquoted strings on either side of a quoted string are subject to
being recognized as macro names. In the following example, quoting the
empty string allows for the dnl
macro to be recognized as such:
define(`macro', `di$1') macro(v)`'dnl |
Without the quotes, this would rather yield the string `divdnl' followed by an end of line.
Quoting may prevent recognizing as a macro name the concatenation of a macro expansion with the surrounding characters. In this example:
define(`macro', `di$1') macro(v)`ert' |
the input will produce the string `divert'. If the quote was
removed, the divert
builtin would be called instead.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When a name is seen, and it has a macro definition, it will be expanded as a macro.
If the name is followed by an opening parenthesis, the arguments will be collected before the macro is called. If too few arguments are supplied, the missing arguments are taken to be the empty string. If there are too many arguments, the excess arguments are ignored.
Normally m4
will issue warnings if a builtin macro is called
with an inappropriate number of arguments, but it can be suppressed with
the `-Q' command line option. For user defined macros, there is no
check of the number of arguments given.
Macros are expanded normally during argument collection, and whatever commas, quotes and parentheses that might show up in the resulting expanded text will serve to define the arguments as well. Thus, if foo expands to `, b, c', the macro call
bar(a foo, d) |
is a macro call with four arguments, which are `a ', `b', `c' and `d'. To understand why the first argument contains whitespace, remember that leading unquoted whitespace is never part of an argument, but trailing whitespace always is.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Each argument has leading unquoted whitespace removed. Within each argument, all unquoted parentheses must match. For example, if foo is a macro,
foo(() (`(') `(') |
is a macro call, with one argument, whose value is `() (() ('.
It is common practice to quote all arguments to macros, unless you are sure you want the arguments expanded. Thus, in the above example with the parentheses, the `right' way to do it is like this:
foo(`() (() (') |
It is, however, in certain cases necessary to leave out quotes for some arguments, and there is nothing wrong in doing it. It just makes life a bit harder, if you are not careful.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When the arguments, if any, to a macro call have been collected, the macro is expanded, and the expansion text is pushed back onto the input (unquoted), and reread. The expansion text from one macro call might therefore result in more macros being called, if the calls are included, completely or partially, in the first macro calls' expansion.
Taking a very simple example, if foo expands to `bar', and bar expands to `Hello world', the input
foo |
will expand first to `bar', and when this is reread and expanded, into `Hello world'.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |