> "Rod Taylor" <rbt@zort.ca> writes:
> > Changing ColLabel to ColId seems to have corrected the problem but
now
> > I'm completely confused as to how it works.
>
> Well, you don't really need to know anything about the parsing
algorithm
> to see that the way you had it was ambiguous. Consider input
> DEFAULT = foo
> If DEFAULT can be a ColLabel, then there are two valid parsings of
> this input: one in which foo is reduced to c_expr and one in which
> it's reduced to a typename. That ambiguity is what creates the
> shift/reduce conflict.
I see.. For some reason I convinced myself that each level was
intepreted by itself, if a match couldn't be found it would dig down
rule. That is, take the first matching depth it finds. Conflicts
were generated by 2 matches at the same deptch. In this case ColLabel
is a subrule, where DEFAULT is a direct match to 'default'.
Makes alot more sense to pre-resolve the tree when I think about it.
I'm used to working with interpreted languages where something like
that would kill a ton of CPU for a majority of cases, but when it's
compiled it only needs to be resolved once; of course.
