Question

I have an EBNF grammar that has a few rules with this pattern:

sequence ::=
    item
    | item extra* sequence

Is the above equivalent to the following?

sequence ::=
    item (extra* sequence)*

Edit

Due to some of you observing bugs or ambiguities in both sequences, I’ll give a specific example. The SVG specification provides a grammar for path data. This grammar has several producers with this pattern:

lineto-argument-sequence:
    coordinate-pair
    | coordinate-pair comma-wsp? lineto-argument-sequence

Could the above be rewritten as the following?

lineto-argument-sequence:
    coordinate-pair (comma-wsp? lineto-argument-sequence)*

Answer 1

Not really, they seem to have different bugs. The first sequence is ambiguous around “item” seeing that “extra” is optional. You could rewrite it as the following to remove ambiguity:

sequence3 ::= 
    item extra* sequence3

The second one is ambigous around “extra”, seeing as it is basically two nested loops both starting with “extra”. You could rewrite it as the following to remove ambiguity:

sequence4 ::=
    item ((extra|item))*

Your first version will likely choke on an input sequence consisting of a single “item” (it depends on the parser implementation) because it won’t disambiguate.

My rewrites assume you want to match a sequence starting with “item” and optionally followed by a series of (0 or more) “item” or “extra” in any order.

e.g.

item
item extra 
item extra item
item extra extra item
item item item item 
item item item item extra

etc.

Without additional information I would be personally inclined towards the option I labled “sequence4” as all the other options are merely using recursion as an expensive loop construct. If you are willing to give me more information I may be able to give a better answer.

EDIT: based on Jorn’s excellent observation (with a small mod).

If you rewrite “sequence3” to remove recursion you get the following:

sequence5 ::= 
    (item extra*)+

It think this will be my prefered version, not “sequence4”.

I have to point out that all three versions above are functionally equivalent (as recognizers or generators). The parse trees for 3 would be different to 4 and 5, but I cannot think that that would affect anything other than perhaps performance.

EDIT:
Concerning the following:

lineto-argument-sequence:
    coordinate-pair
    | coordinate-pair comma-wsp? lineto-argument-sequence

What this production says is that a lineto-argument-sequence is composed of at least one coordinate-pair followed by zero or more coordinate-pairs seperated by optional white/comma. Any of the following would constitute a lineto-argument-sequence (read -> as ‘becomes’):

1,2        -> (1, 2)
1.5.6      -> (1.5, 0.6)
1.5.06     -> (1.5, 0.06)
2 3 3 4    -> (2,3) (3,4)
2,3-3-4    -> (2,3) (-3,-4)
2 3 3      -> ERROR

So a coordinate-pair is really any 2 consecutive numbers.

I have mocked up a grammar in ANTLR that seems to work. Note the pattern used for lineto_argument_sequence is similar to the one Jorn and I recommended previously.

grammar SVG;

lineto_argument_sequence
    : coordinate_pair (COMMA_WSP? coordinate_pair)*
    ;

coordinate_pair
    : coordinate COMMA_WSP? coordinate
    ;

coordinate
    : NUMBER
    ;

COMMA_WSP
    : ( WS+|WS*','WS*) //{ $channel=HIDDEN; }
    ;

NUMBER
    : '-'? (INT | FLOAT) ;

fragment
INT
    : '0'..'9'+ ;

fragment
FLOAT
    : ('0'..'9')+ '.' ('0'..'9')* EXPONENT?
    | '.' ('0'..'9')+ EXPONENT?
    | ('0'..'9')+ EXPONENT
    ;

fragment
WS  : ' '  | '\t' | '\r' | '\n'  ;

fragment
EXPONENT
    : ('e'|'E') ('+'|'-')? ('0'..'9')+ ;

Given the following input:

2, 3 -3 -4 5.5.65.5.6

it produces this parse tree.

alt text http://www.freeimagehosting.net/uploads/85fc77bc3c.png