Anonymous | Login | Signup for a new account | 2019-02-22 21:06 CET | ![]() |
Main | My View | View Issues | Change Log | Roadmap |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||
0007916 | OCaml | lexing and parsing | public | 2019-02-11 14:22 | 2019-02-12 11:43 | ||||||
Reporter | AltGr | ||||||||||
Assigned To | dim | ||||||||||
Priority | low | Severity | minor | Reproducibility | always | ||||||
Status | assigned | Resolution | open | ||||||||
Platform | OS | OS Version | |||||||||
Product Version | 4.07.1 | ||||||||||
Target Version | Fixed in Version | ||||||||||
Summary | 0007916: Surprising priority of algebraic attributes | ||||||||||
Description | The manual is not very clear about the priority of the postfix `[@foo ]` notation, esp. w.r.t. infix operators. The parser defines it between `::` and INFIXOP1 (`@`, `^`), and in fact, the presence of attributes can change the meaning of an expression, which I find surprising. There may be good reasons for this though ? | ||||||||||
Steps To Reproduce | # 3 + 2 * 4;; - : int = 11 # 3 + 2 [@foo] * 4;; - : int = 20 | ||||||||||
Additional Information | Found this while debugging ocp-indent issue 0000275, https://github.com/OCamlPro/ocp-indent/issues/275 [^] | ||||||||||
Tags | No tags attached. | ||||||||||
Attached Files | |||||||||||
![]() |
|
(0019587) dim (developer) 2019-02-11 14:33 |
I remember changing some of the priorities of attribute attachment. I'll try to find the discussions, but the original motivation was to make the attachment of annotations in record fields and constructors more natural. In the end we decided to make the rules consistent between expressions, types, etc... |
(0019588) dim (developer) 2019-02-11 14:37 edited on: 2019-02-11 14:50 |
It was this GPR: https://github.com/ocaml/ocaml/pull/152 [^] which followed this mantis ticket: https://caml.inria.fr/mantis/view.php?id=6612 [^] |
(0019589) AltGr (reporter) 2019-02-11 14:53 |
Ah, indeed I understand the motivation better. In the GPR, only the effects on type definitions are considered, though (and those make sense!) My issue is the result on the parsing of expressions, though. |
(0019590) dim (developer) 2019-02-12 09:10 |
That's true. And the PR actually doesn't change the parsing of expressions. We might have changed the parsing of expressions in a subsequent GPR in order to make everything more homogeneous. Maybe the rule we used wasn't the best one, and instead it could have been: attach the attribute to the biggest syntactic element possible without changing the parsing. i.e. erasing attributes in the source code should yield the same AST modulo attributes. It's probably quite a lot of work to change that now though. |
![]() |
|||
Date Modified | Username | Field | Change |
2019-02-11 14:22 | AltGr | New Issue | |
2019-02-11 14:33 | dim | Note Added: 0019587 | |
2019-02-11 14:37 | dim | Note Added: 0019588 | |
2019-02-11 14:50 | dim | Note Edited: 0019588 | View Revisions |
2019-02-11 14:51 | dim | Assigned To | => dim |
2019-02-11 14:51 | dim | Status | new => assigned |
2019-02-11 14:53 | AltGr | Note Added: 0019589 | |
2019-02-12 09:10 | dim | Note Added: 0019590 |
Copyright © 2000 - 2011 MantisBT Group |