Re: [PATCH 8/9 V3] Add documentation for the new DTS language.

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

David Gibson wrote:
> The current device tree description is purely declarative, but this
> proposal would make it a rather odd hybrid of declarative and
> imperative components.  I do think this could be confusing,
> particularly to device tree newcomers who may not realise which
> components are compile time evaluated and which go into the output
> tree.  I had in mind a rather more functional-programming style for
> macros/computed properties to ameliorate this.
> 
> The several new components of not-C-feel syntax worry me greatly.

Wouldn't a "more functional-programming style" be further away from C?

> If
> you recall the one time I stepped away from C-inspired syntax in the
> original language (bare hex constants), turned out to be a big mistake
> requiring an incompatible source format change to fix.  I really want
> to avoid doing that again, if we possibly can.

If you really want to be as much like C as possible, nothing's stopping 
you from just defining the data structures in real C. :-P

Bare hex constants being a bad idea was not purely due to it being 
different from C.

We also have a substantial difference in the syntax of node/property 
definitions, which forces syntax differences in other parts of the 
lanugage to avoid ambiguity.

> I'm also concerned about adding language-level functions to the
> language.  This requires us to have runtime notions of type and
> symbols and carry them around for evaluation.  I still favour a
> macro-expansion style preprocessing stage instead of semantic-level
> functions for several reasons:
> 	- it provides high flexibility for low conceptual complexity
> 	- we don't have to carry around run-time evaluation structures
> 	- it's a form familiar to C programmers from the preprocessor

I vote against anything similar to the C preprocessor.

-Scott