headers
Víctor M. González | 2 Jan 23:22
Picon

Precedence and "overloaded" operators

Hi.

Given the following operators:

%left '+' '-'
/*...*/
%right SOME_UNARY_OPERATOR
%left STRING_CONCATENATION

And the following rules:

integer:
    SOME_UNARY_OPERATOR string ;

string:
    STRING |
    string '+' string %prec STRING_CONCATENATION ;

Bison can't figure out the correct precedence for "string '+' string", 
and no matter what I do, the report insists that ('+' < 
STRING_CONCATENATION), which is a problem because it understands the 
string (SOME_UNARY_OPERATOR "str"+"ing") as ((SOME_UNARY_OPERATOR 
"str")+"ing"), which is a syntax error.
However, if I leave out the first '+' (the one just above the /*...*/), 
it finally works as it should.
I can also get around it if I change the troublesome rule to
STRING '+' string %prec STRING_CONCATENATION
That forces Bison to delay the reduction of the rule, but at the cost of 
stack space.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joel E. Denny | 3 Jan 18:38
Favicon

Re: Precedence and "overloaded" operators

On Sat, 2 Jan 2010, "Víctor M. González" wrote:

> Given the following operators:
> 
> %left '+' '-'
> /*...*/
> %right SOME_UNARY_OPERATOR
> %left STRING_CONCATENATION
> 
> And the following rules:
> 
> integer:
>    SOME_UNARY_OPERATOR string ;
> 
> string:
>    STRING |
>    string '+' string %prec STRING_CONCATENATION ;
> 
> Bison can't figure out the correct precedence for "string '+' string", and no
> matter what I do, the report insists that ('+' < STRING_CONCATENATION),

That is the precedence you declared, but it shouldn't be relevant for your 
example input, which has only one '+'....

> which
> is a problem because it understands the string (SOME_UNARY_OPERATOR
> "str"+"ing") as ((SOME_UNARY_OPERATOR "str")+"ing"), which is a syntax error.

You appear to have omitted part of you grammar, so my analysis is a guess.  
Specifically, what's the context of integer?  In order for the parse you
(Continue reading)

Permalink | Reply | 0 comments |
headers
Víctor M. González | 3 Jan 21:43
Picon

Re: Precedence and "overloaded" operators

(Sorry about the long message, but I accidentally dropped the mailing 
list when replying to Joel. This is our exchange.)

I wrote:
>>
>> That is the precedence you declared, but it shouldn't be relevant for 
>> your example input, which has only one '+'....
>>   
> Ah... Sorry, I got mixed up. The report says: "Conflict between rule 
> 37 and token '+' resolved as reduce ('+' < LCHK)."
> LCHK is the unary operator I mentioned in my previous post. '+' in 
> this case refers, or should refer, to the one used for string. Unless 
> I'm reading this wrong, Bison seems to be confusing the '+' that's 
> used for numerical expressions and the '+' that's used for string 
> concatenation, which I told it is supposed to have the same precedence 
> as STRING_CONCATENATION, which, in turn, is supposed to be higher than 
> LCHK's, not lower.
>
>> You appear to have omitted part of you grammar, so my analysis is a 
>> guess.  Specifically, what's the context of integer?  In order for 
>> the parse you describe to be correct, it looks like '+' would have to 
>> be able to appear after integer in your grammar.  Can it?
> Here's a more complete version:
>
> integer:
>    INTEGER ;
>
> expr:
>    integer |
>    expr '+' expr |
(Continue reading)

Permalink | Reply | 0 comments |
headers
Akim Demaille | 4 Jan 09:40
Picon
Gravatar

Re: %prec using undefined token


Le 30 déc. 2009 à 10:57, Joel E. Denny a écrit :

> On Wed, 30 Dec 2009, Joel E. Denny wrote:
> 
>> The patch below restores the complaint (as an error not a warning) for the 
>> case when a %prec symbol is not defined, but it maintains the complaint 
>> for the case when the symbol is a nonterminal.  This patch might break 
>> compatibility with Bison 2.4 and 2.4.1.  I'm trying to decide if I should 
>> rewrite it to be a warning in Bison 2.4.2 but an error in Bison 2.5 and 
>> later.
> 
> I've decided I should, and I've found an easy way to do it.  I'm planning 
> to push the first patch below to branch-2.4.2.  I'm planning to push both 
> patches below to branch-2.5 and master.  I'll wait a little for comments.

I agree you chose the best path.
Permalink | Reply | 1 comment |
headers
Joel E. Denny | 4 Jan 18:38
Favicon

Re: %prec using undefined token

On Mon, 4 Jan 2010, Akim Demaille wrote:

> Le 30 déc. 2009 à 10:57, Joel E. Denny a écrit :
> 
> > On Wed, 30 Dec 2009, Joel E. Denny wrote:
> > 
> >> The patch below restores the complaint (as an error not a warning) for the 
> >> case when a %prec symbol is not defined, but it maintains the complaint 
> >> for the case when the symbol is a nonterminal.  This patch might break 
> >> compatibility with Bison 2.4 and 2.4.1.  I'm trying to decide if I should 
> >> rewrite it to be a warning in Bison 2.4.2 but an error in Bison 2.5 and 
> >> later.
> > 
> > I've decided I should, and I've found an easy way to do it.  I'm planning 
> > to push the first patch below to branch-2.4.2.  I'm planning to push both 
> > patches below to branch-2.5 and master.  I'll wait a little for comments.
> 
> I agree you chose the best path.

Thanks, Akim.  I pushed them.
Permalink | Reply | 0 comments |
headers
Joel E. Denny | 4 Jan 18:55
Favicon

Re: %prec using undefined token

On Wed, 30 Dec 2009, Florian Krohm wrote:

> It'd be helpful for debugging grammars to have a warning that is triggered
> when a name is referred to that is not explicitly declared as non/terminal.
> That's less cumbersome than digging through the report file.
> Perhaps something to consider for the next version.

According to POSIX, putting an identifier in a %token, %left, %right, or 
%nonassoc is sufficient to declare it as a token.  (Our master branch also 
has %precedence.)  Otherwise, it's a nonterminal and it's an error not to 
put it on the LHS of a grammar rule.  I interpret that last part to mean 
that (1) putting it on the LHS of a grammar rule declares it to be a 
nonterminal, and (2) an error must be reported if it's never declared as a 
token or nonterminal.  After the patches I just applied, I believe Bison 
now implements all of that fully.

Maybe I don't know what you mean.  Do you have an example where a new 
warning would be helpful?
Permalink | Reply | 1 comment |
headers
Michael Walton | 11 Jan 21:03
Picon
Favicon

problem with automake and bison

I also sent this same message to bug-automake <at> gnu.org. I don't think that it
is technically a bison bug, but I am sending it to the bison bug list in case
any Bison people are interested and can prod the automake people into doing something,
or have suggestions about a proper way to handle it.

I am using the autotools in combination with GNU Bison and Flex. In
particular I am using the %glr directive in my bison file (parse.y).
Everything works fine, except that when I run 'make', 'ylwrap' is
invoked which runs 'bison -y -d' on 'parse.y' producing 'y.tab.h' and
'y.tab.c'. 'ylwrap' then renames these output files to 'parse.h' and
'parse.c' (Forgive me if I have the details wrong. I claim no
expertise). The problem is that the y.tab.c produced from the glr
skeleton with the -d bison option has in '#include "y.tab.h"' CPP
directive in it. This really should be changed by ylwrap to '#include
"parse.h"', but it isn't. The autotools do nothing about this problem.

I am attaching my 'parse.y' file. You can run bison -y -d on it to
simulate the problem. Notice that in the resulting y.tab.c file, there
is an "#include y.tab.h" line. This line won't work because y.tab.h will
be changed to parse.h by ylwrap (or however its done).

As a work around I inserted the following lines into ylwrap.
base=`basename $target .c`
echo $target
mv $target $target.tmp
sed -e 's,y.tab.h,'$base'.h,g' $target.tmp > $target

This works for now but I rather not have to have workarounds. I am
attaching my modified ylwrap file, my parse.y file and my Makefile.am.
(Continue reading)

Permalink | Reply | 0 comments |
headers
tys lefering | 13 Jan 20:59
Picon
Picon
Favicon

error: ‘else’ without a previous ‘if’

Hi,
when updating today bison, gnulib and autoconf from git repo
and installing bison the generated yacc parser does not compile
with this error when using gcc or g++:

y.tab.c: In function ‘yyparse’:
y.tab.c:5998: error: ‘else’ without a previous ‘if’

used the YYERROR_VERBOSE in the parser code like this:

/* let parser print verbose error message at parse error */
#define YYERROR_VERBOSE 1

source code part of the parser is here
  /* If not already recovering from an error, report this error.  */
  if (!yyerrstatus)
    {
      ++yynerrs;
#if ! YYERROR_VERBOSE
      yyerror (YY_("syntax error"));
#else
      while (1)
        {
          int yysyntax_error_status =
            yysyntax_error (&yymsg_alloc, &yymsg, yystate, yytoken);
          if (yysyntax_error_status == 2 && 0 < yymsg_alloc)
            {
              if (yymsg != yymsgbuf)
                YYSTACK_FREE (yymsg);
              yymsg = (char *) YYSTACK_ALLOC (yymsg_alloc);
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joel E. Denny | 13 Jan 21:51
Favicon

Re: error: ‘else’ without a previous ‘if’

Hi Tys,

On Wed, 13 Jan 2010, tys lefering wrote:

> when updating today bison, gnulib and autoconf from git repo
> and installing bison the generated yacc parser does not compile
> with this error when using gcc or g++:
> 
> y.tab.c: In function ?yyparse?:
> y.tab.c:5998: error: ?else? without a previous ?if?

> source code part of the parser is here

>           if (yysyntax_error_status == 0)
>             yyerror (yymsg);
>           else  /* <-- y.tab.c:5998: error: ?else? without a previous ?if?*/
>             yyerror (YY_("syntax error"));

> when changing parser code to this adding '{' and '}' gcc / g++ does accept
> it:
> 
> if (yysyntax_error_status == 0) {
>   yyerror (yymsg);
> } else {
>   yyerror (YY_("syntax error"));
> }
> 
> any solution ? maybe add the '{' '}' in the yacc parser code ?

yyerror is supposed to be a function according to the Bison manual, but
(Continue reading)

Permalink | Reply | 1 comment |
headers
Richard Barton | 13 Jan 18:16
Favicon

License exception wording has not been updated for parse-gram.h

Hi

The wording of the 'special exception' to the GPL license in parse-gram.c was changed in Bison 2.2 but the
exception was not updated in parse-gram.h

parse-gram.h still reads:

/* As a special exception, when this file is copied by Bison into a
   Bison output file, you may use that output file without restriction.
   This special exception was added by the Free Software Foundation
   in version 1.24 of Bison.  */

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be
privileged. If you are not the intended recipient, please notify the sender immediately and do not
disclose the contents to any other person, use it for any purpose, or store or copy the information in any
medium.  Thank you.
Permalink | Reply | 1 comment |

Gmane