Has anyone used the "selection preferences" provided by MKS Yacc?

Question

Since I've gotten no answer at all to my question Is there an alternative to MKS Yacc that supports selection preference syntax or something very similar?, I'll ask the more basic question:

• Has anyone used the "selection preferences" provided by MKS Yacc?

If you have, what did you use it for? Also, does it make any sense to use it in anything other than the last position in a rule?

I have to look after a grammar which figures rules such as:

    TOKEN1 LPAREN non_terminal1 [^EQUAL] TOKEN2 non_terminal2 RPAREN

Unless I'm misunderstanding something, the embedded selection preference doesn't provide any value whatsoever in this context.

Background

MKS Yacc supports a notation which their web site calls "selection preference syntax". It isn't illustrated, but it consists of a token or list of tokens in square brackets with a caret (which might be optional), and it indicates that the particular token must not follow this construct, but that token is not counted as part of this rule:

non_terminal1:  TOKEN1 non_terminal2 TOKEN2 [^TOKEN3]

So, this rules says that a TOKEN1 followed by a non_terminal2 and a TOKEN2 is a non_terminal1, unless the next token is a TOKEN3 in which case some other rule applies.

(I'm not clear whether the bracketed item can be a non-terminal. The code I've seen using the notation always uses a token or a couple of space separated tokens, and never a non-terminal. I'm also not clear whether the caret is required; again, all the examples I've seen use the caret.)

Answer 1

Jonathan. at 1:30 AM I'm not prepared to try to do this myself, but whatever those rules do, they can only be shorthand for rules that could be written in something like normal BNF. Looking at this, it appears that what the "selection preference" is doing is allowing you to express what would otherwise be several productions with one grammar rule.

I did a little digging and found this, which confirms my supposition: what the selection preference does is lets you explicitly insert a lookahead, so that rules which would otherwise be in conflect can be disambiguated.

What I'd suggest is to think about what one of these rules would look like if re-written into yacc or straight BNF. I suspect it will turn out something like

TOKEN1 LPAREN non_terminal1 MULT TOKEN2 non_terminal2 RPAREN
TOKEN1 LPAREN non_terminal1 DIVIDE TOKEN2 non_terminal2 RPAREN
TOKEN1 LPAREN non_terminal1 ADD TOKEN2 non_terminal2 RPAREN
TOKEN1 LPAREN non_terminal1 SUBTRACT TOKEN2 non_terminal2 RPAREN
TOKEN1 LPAREN non_terminal1 EXP TOKEN2 non_terminal2 RPAREN
TOKEN1 LPAREN non_terminal1 MOD TOKEN2 non_terminal2 RPAREN
...

So that the overall effect is to take one rule for every operator except equal, the [^ notation being common in the various Bell Labs languages for something like the complement of a set.