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

I find it ironic that the very first device tree implementation, dating 
back to 1989, was built around a Turing complete language.

On 1/11/2012 11:36 AM, Stephen Warren wrote:

Jon Loeliger wrote at Wednesday, January 11, 2012 7:38 AM:

quoted

quoted

On Tue, Jan 10, 2012 at 01:54:30PM -0800, Stephen Warren wrote:

quoted

John, David,

What can we do to reach consensus on expanding dtc to handle named
constants, or in general any future direction to extend the syntax with
expressions etc.?

Hrm, so, I'm not at all keen to add a named constant syntax without at
least having an outline of what a future macro/function syntax would
look like.

Which is where I thought it was left earlier...? :-)
And it's not just what the macro/function syntax will look like,
but also how these will play into a more generalized expression
handling mechanism.  Defining something one-off now that doesn't
fit well into a long term plan is less than ideal.

Yes, I know that is tantamount to requiring the whole, larger
picture be solved first.  But Dave is right -- at least an outline
of the direction.  Seriously, the lexical problems can form some
of the nastiest gotchas if we're not careful from the onset.

So that all makes sense.

My question is: How can we get consensus on what we want that complete
future syntax to be? IIRC, Jon has a branch that implements a proposal,
and David at least posted a different proposal if not actual code that
implemented it. We're not missing proposals, but rather a mechanism to
decide between them?

For what it's worth, I'd tend towards a simple expression-based syntax
where property values can be calculated with C-style expressions. Basic
math stuff like ( ) + - * /&  | ~<<  >>  and some basic string handling
operations (str(int) and concatenation). I think that'd cover the vast
majority of use-cases wouldn't it? For more advanced stuff like loops
to synthesize multiple nodes, it seems like writing a custom script to
generate the .dts file and then passing the result to dtc would be more
modular, and not require us to create a whole new Turing-complete
language in dtc?