[antlr-interest] Implementation decision help

[Gustaf Johansson]

Thanks for the input Loring,

For the initial conversion I suppose you mean BNF syntax -> Antlr syntax?
That is already done, and was done semi automatic :)

As for the right-factored part, im not sure how to do that with these
problematic rules.
Its easy in a basic example as:
x: ID dot
    | ID comma;
to
x: ID (dot | comma);

But when the difference is 3 rules or more down the grammar it gets
quite hard to get it right.
And i also lose the nice groupings that the grammar has as it is.

Example this rule:
http://www.trex.informatik.uni-goettingen.de/trac/wiki/ttcn-3_4.0.4#CommunicationStatements
Was obviously right-factored and ive left-factored that one but doing
so i got a large rule, which is hard to read and maintain:

communicationStatements:	anyKeyword portKeyword dot (portReceiveOp |
portTriggerOp | portGetCallOp | portGetReplyOp | portCatchOp |
portCheckOp)
				| allKeyword portKeyword dot (portClearOp | portStartOp |
portStopOp | portHaltOp)
				| port dot (portSendOp | portCallOp (portCallBody)? | portReplyOp
| portRaiseOp | portReceiveOp | portTriggerOp | portGetCallOp |
portGetReplyOp | portCatchOp | portCheckOp | portClearOp | portStartOp
| portStopOp | portHaltOp);


And doing the same for the statement rule will make it huge and
probably erroneous.
I don't know if there is some better way than my solution, if so
please enlighten me!

Any help on how to left-factor correctly would be really appreciated.

BR Gustaf

On Wed, Jul 8, 2009 at 3:02 PM, Loring Craymer<lgcraymer at yahoo.com> wrote:
>
> Grammars like this one have usually been developed with LR tools (yacc, bison, ...) and have been right-factored.  What you want is to left-factor the grammar (not just inline the stmtXX bodies as you describe, but also extract new rules to avoid having single large rules.  ANTLRWorks can help.
>
> I also suggest writing a BNF translator to do the initial grammar conversion.  Such translators tend to be quite small (100-300 lines) and are a lot less work than doing the initial conversion by hand.
>
> --Loring
>
>
>
> ----- Original Message ----
>> From: Gustaf Johansson <gustaf.j at gmail.com>
>> To: antlr-interest at antlr.org
>> Sent: Wednesday, July 8, 2009 4:59:08 AM
>> Subject: [antlr-interest] Implementation decision help
>>
>> Hello!
>>
>> I am trying to implement the ETSI TTCN-3 BNF into Antlr.
>> The major part is done and working as it should but there are some
>> quirks which i don't know how to solve.
>>
>> I have rules like this:
>> stm : stmGroup1 | stmGroup2 ... | stmGroupX;
>>
>> And all/some of these stmGroup's can start with the same type of
>> token, but they are distinguishable by some token along the line
>> further down the parse tree.
>>
>> I have tried to solve this by using backtrack=true which didn't work.
>>
>> My current solution is a specific order of the stmGroup's and a few
>> syntactic predicates. But i don't like this solution since i don't
>> know if it will work for all possible input (the grammar is really
>> complex).
>>
>> Basically what i want to accomplish is make Antlr try all of the rules
>> in "stm" and only report error if none of them matches. Currently it
>> reports errors even though a rule later in the list will match the
>> input completely, just because the rule reporting the error matches it
>> partly.
>>
>> The only solution other then syntactic predicates and backtrack i can
>> think of is to combine the stmGroup's into a rule which has truly
>> distinctive paths depending on the next token.
>> Is this the way to do it?
>> It will require a huge amount of work since all the stmGroup's are
>> quite large and complex themselves. Also it will make the grammar
>> almost unreadable.
>>
>>
>>
>> An example of a problematic rule is:
>> http://www.trex.informatik.uni-goettingen.de/trac/wiki/ttcn-3_4.0.4#FunctionStatement
>>
>> These are two parts of that problem:
>> -> ConfigurationStatements -> StartTCStatement
>> -> TimerStatements -> StartTimerStatement
>>
>> PS. backtrack is not used at all in the grammar.
>>
>> BR Gustaf
>>
>> List: http://www.antlr.org/mailman/listinfo/antlr-interest
>> Unsubscribe:
>> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>
>
>
>
>