LR-attributed parser Technique

Question

I would like to know what LR-attributed parsers can do and how it is implemented.

yacc generated parsers allow inherited attributes when the source of the attribute is a sibling that is located to the left using the $0, $-1, etc. specification syntax. With S -> A B B would be able to inherit a synthesized attribute from A but would not be able to inherit something from S. I think this is done by looking down 1 element from B in the stack which would be A.

Now zyacc doc says that they allow for LR-attributes grammars which is I guess more or less the same as yacc allows. Only that with zyacc those attributes are specified with the nonterminal (like parameters) and not just accessed within the semantic action. Are there any other difference like LR-attributes are mightier than the yacc inherited attributes or like LR-attributes are implemented differently (not just looking down the stack).

Ira Baxter · Answer 1 · 2013-06-15T16:17:24.033

The point of LR attributed grammars is to make information seen in the left context, available to the right extension.

Imagine your grammar had

      R -> X S Y;
      S -> A B;

You've already agreed that S can see attributes synthesized from X. In fact, those attributes can be available on the completion of parsing of X. Done properly, those attributes should be available to A and B, as they are parsed, as inherited attributes from S.

YACC doesn't implement any of this to my knowledge, unless you want to count the existence of the parse tree for X as being a "synthesized" attribute of parsing X.

How you implement attributed grammars depends on what you want to do. My company's main product, DMS, uses attribute grammars heavily, with no direction constraints. We simply build the full tree and the propagate the attributes as needed.

What we do is pre-compute, for each node type, the set of attributes [and their types] it may inherit, and the set it may synthesize, and synthesize a struct for each. At attribute evaluation time, these structs are associated with tree nodes via a very fast access hash table. For each node type, we inspect the dataflows (which child consumes which inherited attribute, which children use synthesized attributes from which other children). From that we compute an order of execution to cause all the attributes to be computed in a safe (generated-before-consumed) order and generate a procedure to accomplish this for that node type, which calls children procedures. Attribute evaluation then consists of calling the generated procedure for the grammar root. (In fact, we actually generate a partial order for evaluating the children, and generate a partial-order parallel call using DMS's implementation parallel programming language's capabilities, ensuring fast evaluation using multiple cores on very big ASTs).

There isn't any reason you couldn't limit this process to LR attributes. (Someday we'll push LR-compatible attributes into the parsing phase to allow their use in semantic checks).

It shouldn't surprise you that the device that generates the attribute evaluation process, is itself an attribute-evaluator that operates on grammars. Bootstrapping that was a bit of fun.

Thanks, so you say the difference is that zyacc would allow inheriting attributes that have been synthesized before but not necessarily in the same alternative where those attributes are used? — user764754, Jun 15 '13 at 15:40
Well, *should* allow; I have no idea what zyacc actually does. Why don't you try it? If you write something it can't do, if it is well designed, it will complain. — Ira Baxter, Jun 15 '13 at 16:18

LR-attributed parser Technique

1 Answers1