Hi Cliff, What you've suggested is how I have the production version of the grammar implemented now. However, the language spec that I must conform to specifically states that a text can have zero or more phrases (which is the crux of the problem). I can leave my implementation the way it is and try to have the spec changed, but it would be a heck of a lot easier to just implement to the current spec.
Thanks for the help, Cameron. On Thu, Apr 8, 2010 at 8:49 PM, Cliff Hudson <[email protected]>wrote: > I think you might just have to pop up one level to think about how to > express this - no magic needed. The way that grammar is written, your file > is composed of one or more cltexts, which themselves may be composed either > of a module or any number of phrases (including none at all). It seems to > me this can be re-specified to say that your file may be composed of any > combination of modules and texts, but may also be empty. The empty file > condition should *not* be specified by the closure on phrase but rather as a > top-level rule. For example: > > start_rule > : clif_file > | > ; > > clif_file: > cltext+ ; > > cltext > : module > | text > ; > > text: > phrase+; > > This ensures that each cltext will produce at least something, and no > production from that rule will lead to the EOF condition so there will be no > confusion by ANTLR. > > NOTE: I don't have ANTLR handy to test this... > > > On Thu, Apr 8, 2010 at 1:11 PM, Cameron Ross <[email protected]> wrote: > >> Yes, this is the way I have it implemented in my production version. >> However, I have to conform to a language specification which allows text >> to >> have zero or more phrases. Is there some ANLTR magic that I can use to >> support this? >> >> >> On Thu, Apr 8, 2010 at 4:07 PM, Jim Idle <[email protected]> wrote: >> >> > Your text rule can be empty, you need to rejig your use of + and * or >> you >> > end up with the empty match in more than one place. >> > >> > >> > >> > Jim >> > >> > >> > >> > From: Cameron Ross [mailto:[email protected]] >> > Sent: Thursday, April 08, 2010 1:05 PM >> > To: Jim Idle >> > Subject: Re: [antlr-interest] OPEN, EOF ambiguity >> > >> > >> > >> > These rules give the gist of it... >> > >> > >> > >> > start_rule >> > >> > : clif_file EOF >> > >> > ; >> > >> > >> > >> > clif_file >> > >> > : cltext+ >> > >> > ; >> > >> > >> > >> > cltext >> > >> > : (OPEN CL_MODULE) => module -> ^(CLTEXT module) >> > >> > | text -> ^(CLTEXT text) >> > >> > ; >> > >> > >> > >> > module >> > >> > : OPEN CL_MODULE interpretablename exclusion_set? cltext CLOSE >> -> >> > ^(MODULE ^(MODULE_IDENTIFIER interpretablename) exclusion_set? cltext) >> > >> > ; >> > >> > >> > >> > text >> > >> > : phrase* -> ^(TEXT phrase*) >> > >> > ; >> > >> > ... >> > >> > >> > >> > >> > >> > >> > >> > On Thu, Apr 8, 2010 at 3:57 PM, Jim Idle <[email protected]> >> wrote: >> > >> > You probably need to send the grammar rather than that graphic. It is >> > likely something more fundamental and we cannot see what you predicates >> are >> > doing from the graphic. >> > >> > Jim >> > >> > >> > > -----Original Message----- >> > > From: [email protected] [mailto:antlr-interest- >> > > [email protected]] On Behalf Of Cameron Ross >> > > Sent: Thursday, April 08, 2010 12:34 PM >> > > To: [email protected] >> > > Subject: [antlr-interest] OPEN, EOF ambiguity >> > > >> > > Hi, >> > > >> > > I have a grammar with an ambiguity that I just can't resolve. When I >> > > check the grammar using AntlrWorks I get the following: "Decision can >> > > match input such as "{EOF, OPEN}" using multiple alternatives: 1, 2". >> > > I've attached a screen grab of the syntax diagram generated by >> > > AntrlWorks. I don't understand why ANLTR is thinking that EOF is >> > > ambiguous with OPEN. I've checked the grammar and clif_file is the >> > > only rule that is not referenced from within the grammar, so I don't >> > > think that ANLTR should see module as a start rule. Any help is much >> > > appreciated. >> > > >> > > Cameron >> > >> > >> > >> > >> > >> > List: http://www.antlr.org/mailman/listinfo/antlr-interest >> > Unsubscribe: >> > http://www.antlr.org/mailman/options/antlr-interest/your-email-address >> > >> > >> > >> > >> > -- >> > Kojeware Corporation >> > >> > >> > >> > >> > List: http://www.antlr.org/mailman/listinfo/antlr-interest >> > Unsubscribe: >> > http://www.antlr.org/mailman/options/antlr-interest/your-email-address >> > >> >> >> >> -- >> Kojeware Corporation >> >> List: http://www.antlr.org/mailman/listinfo/antlr-interest >> Unsubscribe: >> http://www.antlr.org/mailman/options/antlr-interest/your-email-address >> > > -- Kojeware Corporation List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups "il-antlr-interest" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
