bison-patches
[Top][All Lists]
Advanced

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

Re: Bison patches


From: Akim Demaille
Subject: Re: Bison patches
Date: Thu, 02 Oct 2003 09:59:25 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

 > Akim Demaille <address@hidden> writes:
 >> Why an argument instead of %no-default-prec and %default-prec?

 > I was thinking that we should allow future extensions, in
 > which there are different flavors of default precedences.  This might
 > become more of an issue with non-LALR parsers.  (I'm being vague here,
 > because I haven't thought it through.)

 > But on second thought let's just go with %no-default-prec for now.
 > Frank's original proposal was more that way, anyway.  We can worry
 > about future extensions (if any) later.

Actually, Frank's purpose is closely related to a long run feature I
wish we had in Bison: an intelligent revamping of precedences.

I don't think we want %default-prec and %no-default-prec: we want a
means to specify independently associativities and precedences.  TODO
says:

| * Precedence
| 
| ** Partial order
| It is unfortunate that there is a total order for precedence.  It
| makes it impossible to have modular precedence information.  We should
| move to partial orders (sounds like series/parallel orders to me).
| 
| This will be possible with a Bison parser for the grammar, as it will
| make it much easier to extend the grammar.
| 
| ** Correlation b/w precedence and associativity
| Also, I fail to understand why we have to assign the same
| associativity to operators with the same precedence.  For instance,
| why can't I decide that the precedence of * and / is the same, but the
| latter is nonassoc?
| 
| If there is really no profound motivation, we should find a new syntax
| to allow specifying this.
| 
| ** RR conflicts
| See if we can use precedence between rules to solve RR conflicts.  See
| what POSIX says.



I'm not fond of contexts, and that's what this patch installs
(actually that's also why I didn't not answer before, I did not think
it would be included for the next release).  For instance, maybe we
want to say

%left-associative '+' '*'

and this implies not precedence at all.  That's cleaner, IMHO.  Or

%left '+'
%left '*'
%%
exp: exp '+' exp %no-prec
   | exp '*' exp %no-prec



The point currently being addressed is very valid, but I believe there
is more to be done.   For instance, I cannot describe

   '+' < '*'

in *parallel* with

   '\/' > '/\'

because whether I write

%left '+'
%left '*'
%left '\/'
%left /\'

or

%left '\/'
%left /\'
%left '+'
%left '*'

I have said more that I meant.  This point is critical when thinking
about %including grammars into one (when %importing actually).

That's why I'm referring to series-parallel orders.  Maybe we want to
say something like:

%parallel
{
  %left '+'
  %left '*'
}
{
  %left '\/'
  %left /\'
}

That is to say, in the present case, we don't want
%(no-)?default-prec, but

%parallel {%left '+'} {%left '*'}
%%
exp: exp '+' exp
   | exp '*' exp





reply via email to

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