help-bison
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]