They're optional productions, and they work perfectly - this is (as far as 
I can tell) the only way to express optional productions in Marpa. The 
"sep" production is not at all ambiguous, actually - you're guaranteed 
non-ambiguity by the context of the production (which is why they're called 
context-sensitive grammars in the first place, an insight that really 
rocked my word late one night...)

You're not used to seeing this because if you discard whitespace you'll 
never even notice this happening - whitespace tokens can break up other 
things but they'll never be explicitly shown in your results.

On Friday, May 2, 2014 2:47:53 AM UTC+2, Christopher Layne wrote:
>
> On May 1, 2014, at 17:30, Jeffrey Kegler 
> <[email protected]<javascript:>> 
> wrote: 
>
> > If you use them inconsistently, it can't do this and complains.  One of 
> its messages of complaint is the one you got. 
>
> In essence this is an ambiguous or possibly even impossible parse, right? 
>
> > On 05/01/2014 02:43 PM, Michael Roberts wrote: 
> >> line ::= name_group sep parmgroup sep sigil sep comment 
> >> name_group ::= tag | tag whitespace names 
> >> 
> >> sep ::= whitespace 
> >> sep ::= 
> >> whitespace ~ [\s]+ 
> >> 
> >> sigil ::= ':' | '::' | ':*' | '{' | '[' | '<' | '(' 
> >>       | sigil template_spec 
> >> sigil ::= 
>
> Question to how others handle things like sep and sigil above. Since they 
> appear nullable is one not actually trying to say in essence that it's 
> optional? 
>
> I usually do something like make this (some chars ommited): 
>
> line ::= stuff sep_opt sigil_opt stuff 
> sep_opt ::= sep* 
> sep ::= sepword 
> sigil_opt ::= sigil* 
> sigil ::= sigilword 
>
> sepword ~ whitespace 
> sigilword ~ ':' 
>
> As a way of expressing 0 or 1 of sep or sigil to indicate it's optional. 
> Am I making life hard for myself and should instead be using nullable 
> alternatives? 
>
> Related to this, this is definitely one area where it seems like life 
> would be easier if the scanless interface supported sep? and sigil? or even 
> just straight quantified rules since it's capable of internally 
> synthesizing rules like the above and one cannot use sep* and sigil* unless 
> they're the only quantified rhs rule. The latter is almost always able to 
> be "wrapped" and if scanless could do it automatically it would speed up 
> writing grammars. Thoughts? 
>
> -cl

-- 
You received this message because you are subscribed to the Google Groups 
"marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to