Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007916OCamllexing and parsingpublic2019-02-11 14:222019-02-12 11:43
ReporterAltGr 
Assigned Todim 
PrioritylowSeverityminorReproducibilityalways
StatusassignedResolutionopen 
PlatformOSOS Version
Product Version4.07.1 
Target VersionFixed in Version 
Summary0007916: Surprising priority of algebraic attributes
DescriptionThe 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 InformationFound this while debugging ocp-indent issue 0000275, https://github.com/OCamlPro/ocp-indent/issues/275 [^]
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(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.

- Issue History
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
Powered by Mantis Bugtracker