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

[David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>]

On Wed, Oct 01, 2008 at 10:26:27AM -0500, Scott Wood wrote:
> 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?

Yes and no - the preprocessor aspects of C are roughly
functional-programming style, at least in the sense I'm intending
here.  Besides, it's not the language as a whole that's supposed to be
like C - clearly it's not - it's the syntactic feel.  The idea is to
make syntactic analogies with C wherever possible, so that C
programmers writing dts files won't find themselves continually making
little syntactic mistakes.

>> 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.

Yes.  But I think insufficient thought has gone into the current
proposal as to how to avoid ambiguity where we have to, while keeping
the C-syntactic-feel as much as possible.

>> 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.

Why?

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson