Subj : Re: The root of the syntax tree
To   : joao
From : Brendan Eich
Date : Wed Jul 07 2004 12:59 pm

Brendan Eich wrote:
> joao wrote:
> 
>> You're right, of course. I see now that the comment groups NAME, STRING,
>> and OBJECT together, under the 'name' variant. But this is strange :
>> when I look inside the JSParseNode, token type is TOK_STRING but
>> pn_arity is PN_NULLARY, not PN_NAME... and yet, there is a
>> pn_u.name.atom field. I assumed pn_arity would be the discriminating
>> field for the pn_u union ?
>>
>> Shouldn't the TOK_STRING have arity PN_NAME ?
> 
> 
> 
> Good point!  I'll fix this nit when the trunk opens again.


Actually, I recall my design decision now.  PN_NULLARY is accurate, 
there are no JSParseNode kids of a TOK_STRING (or of a TOK_OBJECT). 
PN_NAME, on the other hand, denotes a TOK_NAME or TOK_DOT node, which 
may or must (respectively) have a non-null pn_expr "child".  Because 
this pn_expr link may be null, and because of the other distinct members 
of the pn_u.name variant such as atom, I made another "arity" than 
PN_UNARY to distinguish TOK_NAME, TOK_DOT, and any similar future types.

So you should not take PN_NULLARY to mean "not a literal".  Arity has to 
do with tree node child count, and a literal string or object is always 
a leaf node: zero kids.  That does not mean it can't have ad-hoc leaf 
data, e.g., pn_atom.

/be

.