New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nonassoc in ocamlyacc #5462
Comments
Comment author: @mlasson Actually it seems to be a bug in Berkeley Yacc (byacc) I join a new file parser.y which will present the same If you want to test it, you just need to execute :
After a quick search, it seems that noone is complaining |
Comment author: @protz 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 |
Comment author: mehdi 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. |
Comment author: @protz 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 :). |
Comment author: mehdi 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 |
Comment author: @protz 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. |
Original bug ID: 5462
Reporter: @mlasson
Assigned to: @protz
Status: closed (set by @xavierleroy on 2013-08-31T10:46:06Z)
Resolution: won't fix
Priority: low
Severity: minor
Version: 3.12.0
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @protz mehdi
Bug description
Hello,
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
%token PLUS
%token LPAREN RPAREN
%token EOL
%nonassoc PLUS
%start main / the entry point */
%type main
%%
main:
expr EOL { $1 }
;
expr:
INT { $1 }
| LPAREN expr RPAREN { $2 }
| expr PLUS expr { $1 + $3 }
;
File attachments
The text was updated successfully, but these errors were encountered: