|Using functional notation to extend BNF firstname.lastname@example.org (Bill Fenlason) (2007-01-08)|
|Re: Using functional notation to extend BNF email@example.com (Daniel C. Wang) (2007-01-09)|
|Re: Using functional notation to extend BNF firstname.lastname@example.org (Roar) (2007-01-09)|
|Re: Using functional notation to extend BNF RLake@Oxfam.org.uk (2007-01-15)|
|Date:||9 Jan 2007 13:30:35 -0500|
|Posted-Date:||09 Jan 2007 13:30:35 EST|
> commaList(1) ::= 1 | commaList(1) "," 1 ;
> separatedList(1,2) ::= 1 | separatedList(1,2) 2 1 ;
Now, I guess most people are using parser generators, and have to
follow BNF of EBNF notation for those to work.
When one implements all from scratch, one is free to invent anything.
I see you work with separated lists here, using recursive rules. How
about instead stating that lists may have an optional separator
element, so that if it matches more than once, it must match separator
With separator elements being tokens or non-terminals alike.
Most lists in computer languages seem to be separated by simple things
like comma, and it seems odd to introduce all those recursive
constructs to match such a common yet simple language part.
As I see it, BNF is just a thought-organizing tool, a way of expressing
and later implementing a way of recognizing program code. The less
recursion, the better, since recursion is harder to understand reading
it, and harder to implement. Having to first use a lot of
left-recursive rules, then applying the standard formulae for
dispelling it, creating additional (cryptic) productions, is not very
I have formulated a mostly complete, though not verified, grammar for a
java-like language, completely free of left recursion, using the above
mentioned construct, of letting the grammar have the capability of
matching not just sequences of something, but separated sequences.
Maybe I'm missing something here? :-)
Return to the
Search the comp.compilers archives again.