[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Controlling the effects of precedence declarations

From: Frank Heckenbach
Subject: Controlling the effects of precedence declarations
Date: Mon, 12 May 2003 10:52:26 +0200

I generally prefer to avoid precedence declarations in favour of
explicit rules (e.g., multi-level arithmetic nonterminals such as
expression, term, factor etc. instead of a single `expression' with
precedence for `+', `*' etc.).

But there are a few places where this explicit coding would be too
costly, e.g., a dangling else problem in a C-like language which,
AFAIK, would typically require duplication of all rules involved
with `if' and all structured statements that can appear within an
`if' statement. So I do use precedence in a few such places.

Now I'd like to avoid unwanted effects of the precedence
declarations. There will probably be more changes to the grammar in
the future, and it might be that one of them will cause an actual
S/R conflict. With some bad luck, this might involve tokens with a
declared precedence and therefore be resolved automatically by
bison, possibly not in the way intended, and I wouldn't directly
notice this when running bison.

Of course, I could run bison with `-v' and regularly check the
verbose output to see which conflicts were actually resolved by
precedence, but I wonder if there's a more automatic way. (I could
use `%expect', but it only checks how many conflicts there are, and
I can't control how to resolve them since they're always resolved as

I know I can declare precedence of rules using `%prec', and for this
I can use tokens not otherwise used, so they at least won't have
unwanted effects. But for the other side, I have to declare the
precedence of the respective look-ahead token which is, of course, a
regular token.

As an example, say I have a conflict between a rule `foo' and a
look-ahead token `bar' and another one between a rule `baz' and a
token `qux'. So I can declare the following precedences (depending
on how I want to resolve the conflicts, e.g.):

%nonassoc prec_foo  /* not otherwise used */
%nonassoc bar

%nonassoc qux
%nonassoc prec_baz  /* not otherwise used */


foo: ... %prec prec_foo;

baz: ... %prec prec_baz;

But this also gives the tokens bar and qux a relative precedence and
if I ever get a conflict between a rule that ends with `bar' and the
look-ahead token `qux', this would be automatically resolved,
without me noticing.

I had thought I could put `bar' and `qux' into a single `%nonassoc'
declaration, but then they'd only have the same non-associative
precedence, which is not exactly the same as no precedence, because
it would only give an error at runtime when reaching a conflicting
situation, not at bison-time.

I don't know of any way to achieve what I want in bison, but I have
two ideas, both of which would allow this:

- Support precedence classes. So I could put prec_foo and bar in one
  class, and qux and prec_baz in another one. When using
  precedences, bison should only consider tokens in the same class
  (and otherwise behave as if they had no precedence at all).

- Don't assign default precedence to rules (optionally, of course).
  So, only rules with explicit `%prec' declarations get precedence
  and I can be sure that conflicts of other rules are not resolved
  automatically. (I think all it would take is an option, or perhaps
  better a directive in the grammar, to suppress the statement
    if (p->sym->class == token_sym)
      rules[ruleno].prec = p->sym;
  in reader.c: packgram().)

(If this discussion should go to bug-bison because it's about new
feature suggestions, let me know.)


Frank Heckenbach, address@hidden
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

address@hidden http://mail.gnu.org/mailman/listinfo/help-bison

reply via email to

[Prev in Thread] Current Thread [Next in Thread]