Skip to content
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

Printing precedence levels incorrect #67

Open
alberdingk-thijm opened this issue May 17, 2021 · 2 comments
Open

Printing precedence levels incorrect #67

alberdingk-thijm opened this issue May 17, 2021 · 2 comments

Comments

@alberdingk-thijm
Copy link
Collaborator

The current precedence levels used when printing seem to have some minor inconsistencies which lead to the absence or redundancy of parentheses in some places. These occur in a couple different situations:

open Nv_lang
(* a function for reprinting parsed strings *)
let f s = Printing.exp_to_string (Parser.expreof Lexer.token (Lexing.from_string s);;
(* operator function arguments are missing parentheses *)
let s = "foldNodes (fun u -> fun v -> fun acc -> assert_node u v && acc) sol true";;
f s;; (* u"foldNodes fun u~0 -> fun v~0 -> fun acc~0 -> ((assert_node~0 u~0 ) v~0 ) && acc~0    sol~0 true" *)
(* extra parentheses around function bodies *)
let t = "fun u -> fun v -> match (u,v) with | (None, None) -> false | (_, _) -> true";;
f t;; (* u"fun u~0 -> fun v~0 -> (match (u~0,v~0) with \n | (None,None) -> false\n | (_,_) -> true\n)  " *)

I'd like to fix these inconsistencies but I'm not too familiar with how the precedence levels align between the printer and the parser.

@alberdingk-thijm
Copy link
Collaborator Author

@DKLoehr @nickgian can either of you lend any insight into this, or how I could modify prec_exp and the other functions here? I can see that we have some functions where parentheses get added if the precedence is lower than max_prec (func_to_string, closure_to_string) and then in exp_to_string we add parentheses if the precedence is higher in the inner expression relative to the outer one.

@DKLoehr
Copy link
Collaborator

DKLoehr commented May 17, 2021

Don't think I have much to contribute here -- if I were to try to fix this myself I'd probably just try a bunch of examples and see what the parser does, then edit printing to match that. I suspect we probably erred on the side of putting in more parens than necessary to be safe. If there are any cases where the printed version doesn't actually parse to the same thing (especially if parens are missing) that's worth fixing, but I never thought too hard about the inner workings of the printer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants