[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Identifying start of new rule
From: |
Test User |
Subject: |
Re: Identifying start of new rule |
Date: |
Sun, 16 Jun 2013 04:28:13 -0500 |
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.