Mantis Bug Tracker
Main | My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005462OCamlOCaml generalpublic2012-01-03 16:182012-01-23 16:05
Reportermlasson 
Assigned Toprotz 
PrioritylowSeverityminorReproducibilityalways
StatusresolvedResolutionwon't fix 
PlatformOSOS Version
Product Version3.12.0 
Target VersionFixed in Version 
Summary0005462: nonassoc in ocamlyacc
DescriptionHello,

The behavior of nonassoc is not clear to me.

The documentation of yacc says :
"A shift/reduce conflict between a rule and a token with the same precedence will be resolved using the associativity: if the token is left-associative, then the parser will reduce; if the token is right-associative, then the parser will shift. If the token is non-associative, then the parser will declare a syntax error."

On a simple example (see "Steps To Reproduce"), if I declare a binary operator to be non associative, I get no warning and the generated parser seems to behave like the operator was left associative and raises no exception.

It looks like a bug but I may also have misunderstood the keyword nonassoc.

I've tested it on 3.12 and 3.00.
I join archive for observing this behavior.
One just need to untar it and compile with "ocamlbuild main.native" and execute "echo 2+2+2 | ./main.native".

Thank you,
Marc.
Steps To Reproduce
%{
%}

/* File parser.mly */
%token <int> INT
%token PLUS
%token LPAREN RPAREN
%token EOL
%nonassoc PLUS
%start main /* the entry point */
%type<int> main
%%
main:
   expr EOL { $1 }
;
expr:
   INT { $1 }
 | LPAREN expr RPAREN { $2 }
 | expr PLUS expr { $1 + $3 }
;
TagsNo tags attached.
Attached Filestgz file icon calc.tgz [^] (126,920 bytes) 2012-01-03 16:18
? file icon parser.y [^] (1,017 bytes) 2012-01-04 14:40

- Relationships

-  Notes
(0006589)
mlasson (reporter)
2012-01-04 14:40

 Actually it seems to be a bug in Berkeley Yacc (byacc)
from which the code of ocamlyacc is adapted.

I join a new file parser.y which will present the same
behavior with byacc and succeed to recognize a syntax
error when invoked with bison.

If you want to test it, you just need to execute :
- For byacc:
  byacc parser.y && gcc y.tab.c && echo "2+2+2" | ./a.out
  which will output 6

- For bison:
  bison parser.y && gcc parser.tab.c && echo "2+2+2" | ./a.out
  which will fail as we expect.

After a quick search, it seems that noone is complaining
about this bug of Berkeley Yacc on the internet.
(0006773)
protz (manager)
2012-01-23 14:06

 Hi,

Thanks for reporting. This is indeed a bug in ocamlyacc. However, we're not actively developing ocamlyacc. It is only kept for the sake of compiling ocaml itself. Menhir <http://cristal.inria.fr/~fpottier/menhir/menhir.html.en> [^] is a modern, efficient parser generator. It is the recommended solution for writing parsers now.

This particular bug has been fixed this morning in menhir's latest release.

Cheers,

jonathan
(0006779)
mehdi (reporter)
2012-01-23 15:43

 What if one day the fix is need by OCaml itself?

Besides, if ocamlyacc is being obsoleted by upstream if favour of Menhir, then it has to be announced or advertized somewhere. (on caml-list and a note in OCaml's manual). Apologies if I missed that announcement.
(0006781)
protz (manager)
2012-01-23 15:57

 Yes, changing the ocaml manual to reflect this fact is on my todo list, as well as writing a short "getting started with menhir" tutorial to be part of the main ocaml manual. When it's done, I'll announce that to the caml-list.

The conflict is very, very specific, and I'm pretty sure we're not about to hit that anytime soon in ocaml :).
(0006782)
mehdi (reporter)
2012-01-23 16:01

 Thanks. I think that Menhir's manual would do the job (as it is well written and rather short) but ymmv.

I agree that it is a specific issue. It is just the "if the fix exists, why don't you apply it?" feeling but anyway…

Regards
(0006783)
protz (manager)
2012-01-23 16:05

 Well I don't think anyone owns ocamlyacc anymore, and I don't think anyone wants to hack on it. But of course, if anyone were to provide a patch, we would most certainly accept it.

- Issue History
Date Modified Username Field Change
2012-01-03 16:18 mlasson New Issue
2012-01-03 16:18 mlasson File Added: calc.tgz
2012-01-04 14:40 mlasson Note Added: 0006589
2012-01-04 14:40 mlasson File Added: parser.y
2012-01-23 14:06 protz Note Added: 0006773
2012-01-23 14:06 protz Status new => resolved
2012-01-23 14:06 protz Resolution open => won't fix
2012-01-23 14:06 protz Assigned To => protz
2012-01-23 15:43 mehdi Note Added: 0006779
2012-01-23 15:57 protz Note Added: 0006781
2012-01-23 16:01 mehdi Note Added: 0006782
2012-01-23 16:05 protz Note Added: 0006783

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker