[antlr-interest] Having trouble with creating a parser for my desired grammar. Running afoul of multiple alternatives warnings

[Jarrod Roberson]

On Tue, Nov 15, 2011 at 5:46 PM, John B. Brodie <jbb at acm.org> wrote:

> Greetings!
>
> I think you have issues with your function, number, and ATOM rules. see
> below...
>
>
apparently I did


> I have attached my complete, modified, grammar that successfully parses
> your input sample.
>
>
thanks for taking the time to fix up my problems, you figured out what I
intended when I couldn't!


> just a nit pick here - you really should include EOF in your topmost rule.
>
>
thanks I was not aware this was something I should do


> >
> > statement : expression
> >           | assignment
> >           ;
> >
> > assignment : ID '->' expression
> >            | ATOM '->' ( string | number )
> >            | function '->' statement ((','statement)=> ',' statement)* ;
>
> I think you are being too liberal here with your function signatures.
> you permit any expression to be a formal argument. are you intending to
> have patterns akin to either ML or Haskell? if not, change the
> definition of function in your assignment rule.
>
>
I am patterning my syntax off what I like about Erlang and Python with some
hopefully streamlining


> I also think that this permits multi-expression body, something like:
>
> foo(a,b)-> a, b.
>
>
I didn't realize it until you said it, but yes I only need to allow a
single expression as the LAST statement because I am having
the LAST statement result be the return value without need a "return"
keyword.


> e.g. a function body consisting of two (or more) expressions. do you
> really want that -- you do if your expressions can have side-effects.
>
>
nope single assignment variables and no side effects if I can help it


> maybe the third alt of assignment rule should be something like
> (assuming you do not have side effects and watch out for i/o!):
>
> | ID '(' ID (',' ID)* ')' '->' (assignment ',')* expression ;
>
> this eliminates the need for a predicate.
>
> >
> > args : expression (',' expression)*;
> >
> > function : ID '(' args ')' ;
> >
> > string : UNICODE_STRING;
> > number : HEX_NUMBER
> >        | (INTEGER '.' INTEGER)=> INTEGER '.' INTEGER
>
> I do not think you want to recognize floating point values in the
> parser. any tokens you send to the HIDDEN $channel (or skip();) will be
> silently accepted before and after the '.' of the float. change your
> INTEGER rule to this:
>
> fragment FLOAT: ;
> INTEGER : DIGIT+ ('.' DIGIT+ {$type=FLOAT;} )? ;
>

actually thanks to Bart I need the FLOAT rule as a parser rule with the
predicate because I want to be able to match

a = 1.
b = 100.1101.


> >
> > ATOM : (('A'..'Z'|'_')+)=> ('A'..'Z'|'0'..'9'|'_')+;
>
> no need for a predicate
>
> ATOM : ('A'..'Z')('A'..'Z'|'0'..'9'|'_')*;
>
> note that this also removes the ambiguity as to whether the string "_"
> is an ATOM or an ID.
>
>
this is what I actually intended, thanks


> >
> > ID : ('a'..'z'|'_')('a'..'z'|'A'..'Z'|'0'..'9'|'_')*;
> >
> > COMMENT : '/*' .* '*/' {$channel = HIDDEN;};
> >
>



-- 
Jarrod Roberson
678.551.2852