Re: syntax howto question

[Hans Aberg]

At 21:47 -0500 2002/11/02, Sean Middleditch wrote:
> I've got a hairy bit of grammar to deal with - I need to be able to
>differentiate in a language between function call and method calls.  The
>syntax for a function may look like
>
>  blah (args);
>
>and for a method
>
>  object.blah (args);

If your language is declarative, then the way to resolve it is to store the
declared types of the identifiers in a lookup table, which then the lexer
can send over to the parser that Bison generates.

> I've got here the grammar snippets giving me pains:
>expr: ...
>       | expr '(' args ')' { ... }
>       | expr '.' name '(' args ')' { ... }
>       | expr '.' name { ... }
>       ...

One can the look say into the C++ grammar that is in its standard to get
ideas of how to write a grammar. It has:
  member-declaration:
   decl-specifier-seq opt member-declarator-list opt ;
   function-definition ;opt
Then Appendix C.1.5 Clause 7.1.5 says:
  In C++ a decl-specifier-seq must contain a type-specifier.
This is unlike C where the type specifier "int" sometimes can be omitted.
-- In C++, the type specifier is needed, because the lexer can then figure
out what type to return to the parser.

> The problem I'm having is that the grammer is not picking up method
>calls right.  It sees  object.blah (args);  as an expression
>(object.blah the member lookup), then puts that into the function call
>expression.  This makes method calls rather not work... I've tried
>giving the function/method calls explicit precedence (the method call
>being higher) like so:

Turn on the debug feature, to see what exactly is parsed (see the manual).

>%nonassoc TFUNCCALL
>%nonassoc TMETHODCALL
>
>expr: ...
>       | expr '(' args ')' %prec TFUNCCALL { ... }
>       | expr '.' name '(' args ')' %prec TMETHODCALL { ... }
>       | expr '.' name { ... }
>       ...
>
> But it helps not.  Bison isn't giving me any shift or reduce errors,
>either.  Any insight on how I can get this working the way I'd like it
>to?

If your language is not declarative, then you must make sure that the
grammar is LALR(1). The %nonassoc can only help resolving certain
shift/reduce conflicts, but not reduce/reduce conflicts.

You can try to rewrote the grammar so that there is a token that clearly
distinguishes between which rule to use. For example, you can distinguish
between methods and data members above if there is an end marker like ";"
in C++:
class_name: ...
        | class_name '(' args ')'
        | class_name '.' name '(' args ')'
        | class_name '.' name ';' { ... }

One way to push down higher LR(n) lookups to LALR(1) that sometimes work is
to make the lexer to makes some extra lookups, and then sequence them out
to the parser.



  Hans Aberg