Re: [PATCH v2] dtc: Add support for named integer constants

[Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>]

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