On 09/20/2011 03:04 AM, David Gibson wrote:

So, there are basically two approaches to macro or function support.

A) Functions

We allow definition of functions with parameters.  These are stored
in some kind of parse tree representation in a symbol table.  Instead
of producing a more-or-less fully realised device tree as we parse, we
produce some kind of parse tree showing the expressions and function
calls.  After parsing is complete we make another pass evaluating all
the expressions and functions.

Advantages:
 * Allows repeats / iteration to be done simply.
 * Potentially allows superior type and other error reporting
 * Jon already has a prototype in the test branch

Disadvantages:
 * Requires a substantial runtime evaluation infrastructure to be
   implemented, including representation and storage of function
   definitions.
 * I don't like Jon's proposed syntax in the test branch because
   although it's C like, it's very much against the current
   declarative feel of dts.  That is, it feels somewhat like a program
   that's executed to produce the device tree rather than a
   representation of the device tree itself

You could say the same thing about macros.  This is just doing it at a
higher semantic level.

  Disadvantages:
   * The # used for preprocessor directives clashes with common
     property names beginning with #.  In practice this can be
     disambiguated by assuming only # in column 0 is for cpp, but the
     options to make cpp behave this way are not necessarily portable.

There are other disadvantages, namely that cpp, while familiar, is not a
very good macro language:
 - No recursive macro expansion ("self-referential" in cpp's terms) --
   useful for iteration in the absence of explicit support
 - No conditionals inside the macro body -- needed to make recursive
   macros work, but also useful on their own
 - Awkward handling of multi-line macro bodies -- backslashes
   everywhere, and makes it difficult/awkward to fix the previous
   issues with incremental extensions of the macro language
 - Does not integrate well with the surrounding language's
   indentation/formatting, especially if the directives need to be in
   column 0

If we're going to use an existing macro language, something more like
the GNU assembler's macros would be nicer.

Another disadvantage of any approach that tries to separate macros from
the underlying language is that you can't have anything be conditional
on an expression that the macro layer doesn't understand.

-Scott