On Sat, Jun 15, 2013 at 11:19 PM, Chris verBurg wrote: > Dear Test, > > I have to start by saying I got a giggle out of your yyerror function, > because I saw the "EEK" and figured out it was my tutorial you read through. > Awesome! Glad it's still useful. :)
Yes, it's the snazzle tutorial. I did not se a need to change yyerror(). I was looking for a tutorial that woudl spare me the theory behind finite state machines LALR(1) parsers, etc. > > I think the core of your problem is this rule: > <expansion> ::= <expansion> <expansion> > which essentially turns <expansion> into an arbitrarily long list, I thought so too. It clearly does not terminate. I was working from an article that I found: [quote] Naturally, we can define a grammar for rules in BNF: rule → name ::= expansion name → < identifier > expansion → expansion expansion expansion → expansion | expansion expansion → name expansion → terminal [/quote] However, I found a Wikipedia article at http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form with a better looking grammar: [quote] BNF's syntax itself may be represented with a BNF like the following: <syntax> ::= <rule> | <rule> <syntax> <rule> ::= <opt-whitespace> "<" <rule-name> ">" <opt-whitespace> "::=" <opt-whitespace> <expression> <line-end> <opt-whitespace> ::= " " <opt-whitespace> | "" ; "" is empty string, i.e. no whitespace <expression> ::= <list> | <list> "|" <expression> <line-end> ::= <opt-whitespace> <EOL> | <line-end> <line-end> <list> ::= <term> | <term> <opt-whitespace> <list> <term> ::= <literal> | "<" <rule-name> ">" <literal> ::= '"' <text> '"' | "'" <text> "'" ; actually, the original BNF did not use quotes This assumes that no whitespace is necessary for proper interpretation of the rule. <EOL> represents the appropriate line-end specifier (in ASCII, carriage-return and/or line-feed, depending on the operating system). <rule-name> and <text> are to be substituted with a declared rule's name/label or literal text, respectively. [/quote] I will try to express this grammar in bison and see how it goes. I will leave out <line-end>. I don't see the point, especially if we consider their example grammar [quote] <postal-address> ::= <name-part> <street-address> <zip-part> <name-part> ::= <personal-part> <last-name> <opt-suffix-part> <EOL> | <personal-part> <name-part> <personal-part> ::= <first-name> | <initial> "." <street-address> ::= <house-num> <street-name> <opt-apt-num> <EOL> <zip-part> ::= <town-name> "," <state-code> <ZIP-code> <EOL> <opt-suffix-part> ::= "Sr." | "Jr." | <roman-numeral> | "" <opt-apt-num> ::= <apt-num> | "" [/quote] <rule> suggests that a BNF rule is terminated by end-of-line, but <name-part> is written on 2 lines. > > I can think of two immediate solutions: > 1. introduce an 'end of rule' marker (such as the infamous semicolon) so > that the arbitrarily long list has a clearly defined end. That would not work for me. I am not defining my own language; I am trying to parse BNF productions like <postal-address> above (minus the end-of-line) so I cannot introduce anything. > 2. turn on GLR parsing so that it'll scan farther ahead before gobbling. I tried that before I posted and it did not work. Regards, Test User. _______________________________________________ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
