Im trying to figure out how the SDF priorities are treated and I found some inconsistencies, or it could well be that I havent cracked the code yet :P

Off the SDF Manual : http://homepages.cwi.nl/~daybuild/daily-books/syntax/2-sdf/sdf.html#section.disambassociativity

we can read the following:
The {left} associativity attribute on a production P filters all occurences of P as a direct child of P in the right-most argument. This implies that {left} is only effective on productions that are recursive on the right (as in A B C -> C).

This makes it possible to parse

5 * 5 * 5 , as (5*5) * 5 when the left associativity attribute is given in the syntax definition ex: Exp “*” Exp -> Exp{left}

However, according to the description it should prohibit the parsing of:

SomeOP ( 5, SomeOP( 5,5) ) for the syntax definition “SomeOP” “(” Exp “,” Exp “)” -> Exp{left}.

This leads me to believe this is only used if the parser comes accross ambiguities, since the syntax definition of SomeOp kinda makes ambiguity impossible, in contrast to the Multiplication operator. However, if one uses the non-assoc attribute:

The {non-assoc} associativity attribute on a production P filters all occurrences of P as a direct child of P in any argument. This implement that {non-assoc} is only effective if a production is indeed recursive (as in A C B -> C).

One would expect SomeOP to still parse, but it doesnt. It seems there the restriction is enforced regardless of ambiguities.

Now if we look at group associativity, it’s more strict and the restriction is always enforced. So is this “soft” enforcing for single associativity a bug? Or should non-assoc be treated as a “no-self-recursion” attribute, instead of a disambiguation function?

Help?

Cheers,
Andre

Submitted by André Vieira on 18 June 2012 at 15:42