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

[Simon Glass]

Hi Grant,

On Thu, Sep 8, 2011 at 11:32 AM, Grant Likely <grant.likely at secretlab.ca> wrote:
> On Thu, Sep 08, 2011 at 06:09:27AM -0700, Simon Glass wrote:
>> Hi Stephen,
>>
>> On Fri, Sep 2, 2011 at 11:34 AM, Stephen Warren <swarren at nvidia.com> wrote:
>> > Stephen Warren wrote at Tuesday, August 30, 2011 3:30 PM:
>> >> You may define constants as follows:
>> >>
>> >> /define/ TWO 2;
>> >> /define/ FOUR 4;
>> >> /define/ OTHER FOUR;
>> >>
>> >> And properties may use these values as follows:
>> >>
>> >> foo = <1 TWO 3 FOUR 5>;
>> >>
>> >> Signed-off-by: Stephen Warren <swarren at nvidia.com>
>> >
>> > David, Jon,
>> >
>> > Does this seem reasonable?
>> >
>> > I think the syntax is simple enough it wouldn't interfere with any more
>> > advanced expression/function/... support in the future, and it could be
>> > easily extended to allow e.g.:
>> >
>> > /define/ FOO "BAR";
>> > /define/ BAX [0af8dacb0];
>> > ...
>>
>> This seems very reasonable to me, and very useful. From the syntax it
>> looks like lower case symbols are allowed also, which is fine with me.
>>
>> I hope that this can go into dtc as we would definitely use it.
>
> What are the risks of symbol conflict with this approach?  I'm
> concerned that a poorly chosen /define/ name will break parsing in
> non-obvious ways.  Would it be better to have a every define reference
> to be explicit in the syntax?

Can you give an example of symbol conflict?

I vote against explicit syntax...things like $var are pretty ugly I
think. We will end up with Perl. Let's make these defines first class
citizens.

It should be clear enough since these will appear within a value -
i.e. I assume we will do:

/define/ ONE 1
...
/ {
   testing = <ONE TWO THREE>;
}

but not:

/define/ which testing
/ {
   which = <1 2 3>;
}

which does seem a little ambiguous (although not unresolveable by the
parser with the help of the symbol table).

Regards,
Simon

>
> g.
>
>