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
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@ozlabs.org
https://ozlabs.org/mailman/listinfo/devicetree-discuss
