Yeah, it turns out that it was the way I was using the rule that was causing the warning. The problem is that depending on the macro definitions that are present ?foo(bar) can mean either "replace this expression with the value of the parameterized macro foo(a)" or "replace foo with the value of the unparameterized macro foo and call the result as a function with the argument bar". I guess I'm going to have to build a pre-processor :-/

T


2013/11/1 David Engster <deng@randomsample.de>
Thomas Järvstrand writes:
> In erlang a macro is written as ?atom or ?atom([arguments])
>
> In my grammar this translates to the rule:
> macro
>   : WHY ATOM PAREN_BLOCK
>   | WHY ATOM
>   ;

First off, even if you get a shift/reduce conflict for this, the default
is to do shift in such a case, so it should still work. Of course, if
the problem is fixable in the grammar, it should be fixed.

> I've tried solving this by changing this to (using %nonassoc because I couldn't
> find any evidence of the %precedence declaration existing in semantic):
> %nonassoc PARAMETERIZED-MACRO
> %nonassoc MACRO

No, %precedence does not exist. However, I think using %nonassoc has
pretty much the same effect. As far as I can see, the difference in
Bison is whether using the operator in an associative way is a run-time
or compile-time error. That being said, I don't think you need to fiddle
with precedence here.

> macro
>   : WHY ATOM PAREN_BLOCK %prec PARAMETERIZED-MACRO
>   | WHY ATOM %prec MACRO
>   ;
>
> But I still get a warning for a shift/reduce conflict when compiling the
> grammar. What is the correct way of solving this issue?

I'd really need to see the full grammar to see the problem (the conflict
might be due to interaction of separate rules), but this problem is
usually dealt with by using an additional rule for an optional argument
which contains an empty match, like

macro
   : WHY ATOM optional-args
   ;

optional-args
   : ;; EMPTY
   | PAREN_BLOCK
     (EXPAND $1 argument-list)
   ;

argument-list:
   : ... deal with open/close-paren and list of arguments ...


You should find many examples like this in other grammars, like in c.by
the optional initialization of variables:

 varname-opt-initializer
   : semantic-list
   | opt-assign
   | ;; EMPTY
   ;

or in java.wy you'll find lots of non-terminals ending in '_opt'.

-David