Re: Bison patches

[Frank Heckenbach]

Akim Demaille wrote:

>  > 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?

AFAIK, associativity doesn't concern only sequences of the same
operator, but also mixed sequences of operators of the same
precedence level. I.e., in this example, what would `a * b / c'
mean? The precendence is the same, so would the associativity of `*'
allow or the non-associativity of `/' forbid this construct?

> 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 is just my concern and why I originally brought up the topic.

What %no-default-prec I'd have to mark `%prec' all rules affected
which is more or less work (depending on how much the grammar relies
on precedences), but at I least I can be sure to avoid any unwanted
effects.

> That's why I'm referring to series-parallel orders.  Maybe we want to
> say something like:
> 
> %parallel
> {
>   %left '+'
>   %left '*'
> }
> {
>   %left '\/'
>   %left /\'
> }

Paul Eggert wrote:

> The points you raise about associativity and partial orders for
> precedences are good ones, but it seems to me that they are somewhat
> orthogonal.  They would affect how precedences behave when invoked,
> but %no-default-prec affects how the precedences are assigned to rules.

I'm not sure if partial orders cover everything that
%no-default-prec does, but for my problem they would work, anyway.
Actually, in my original mail of 12 May I suggested this as an
alternative solution (I wrote "precedence classes").

In the following discussion, mostly with Hans Aberg, I understood
that it was a nice feature -- and Hans suggested another, even more
general feature ("For each production and each of its RHS grammar
variables, one can be allowed to declare a set of parse tree
derivation restrictions.") --, but that such features take more work
and are unlikely to be implemented in the nearer future. So I went
for the one that was less ambitious, but feasible for me to
implement, and solving my problem.

Frank

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