[antlr-interest] Tree rewriting (filter=true, output=ast)

[Sam Barnett-Cormack]

Gavin Lambert wrote:
> You should always list your more-specific alternatives above the
> less-specific ones (so have your nameAndNumberForm above the ~NAMENUM alt).
> 
> Also, label+=(block ...) doesn't actually work -- the label always ends
> up being null.

That's annoying, but easy to bare in mind.

> Not sure if the following will work, but it'd be my first attempt to get
> the behaviour you're wanting:
> 
> valueListValue
> scope { bool hasOther; bool hasNameNum; }
> @init { $valueListValue::hasOther = false; $valueListValue::hasNameNum =
> false; }
>   : ^(VLIST
>     ( v+=nameAndNumberForm { $valueListValue::hasNameNum = true; }
>     | (v+=externalValueReference | v+=LCID | v+=NUMBER)
>     | . { $valueListValue::hasOther = true; }
>     )+
>     ( { $valueListValue::hasNameNum && $valueListValue::hasOther) }? {
> raise error; }
>     | { $valueListValue::hasNameNum }? -> ^(OBJID $v+)
>     )?
>   ;
> 
> (I'm a little unsure about the specific syntax for that last bit.  But I
> think something like that ought to do the trick.)

Apart from a mysterious ')' in your first sempred, it looks right to me.

The choice under VLIST generates warnings, and I guess I just have to
ignore them - it disallowing 3 for those inputs is what I want, after
all. However, the text of the warning mentions the constructs for
nameAndNumberForm and externalValueReference in the raw form, with DOWN
and UP tokens. This makes me worry whether this filter really will only
alter/disallow trees based on their first-tier content, rather than
looking deeper. I'm not sure how much tree parsers really are tree-aware
and how much they're syntactic sugar for parsing based on token streams
with the tree structure tokens DOWN and UP added in. Can anyone clarify
this, or otherwise reassure me? A VLIST might potentially contain
^(OBJID...) constructs underneat it, possibly a long way, and I don't
want to end up with errors because of it.

Sam