<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div>I am currently working annotations into the parser, provided them as a separate structure at the end of the parse, indexed to the original by SrcSpan and AST element type.<br><br></div>The question I have is how to capture commas and semicolons in lists of items.<br><br></div>There are at least three ways of doing this<br><br></div>1. Make sure each of the items is Located, and add the possible comma location to the annotation structure for it.<br><br></div>This has the drawback that all instances of the AST item annotation have the possible comma location in them, and it does not cope with multiple separators where these are allowed.<br><br><br></div>2. Introduce a new hsSyn structure to explicitly capture comma-separated lists.<br><br></div>This is the current approach I am taking, modelled on the OrdList implementation, but with an extra constructor to capture the separator location.<br><br></div>Thus<br><br>```<br>data HsCommaList a<br>  = Empty<br>  | Cons a (HsCommaList a)<br>  | ExtraComma SrcSpan (HsCommaList a)<br>       -- ^ We need a SrcSpan for the annotation<br>  | Snoc (HsCommaList a) a<br>  | Two (HsCommaList a) -- Invariant: non-empty<br>        (HsCommaList a) -- Invariant: non-empty<br>```<br><br><br></div>3. Change the lists to be of type `[Either SrcSpan a]` to explicitly capture the comma locations in the list.<br><br><br></div>4. A fourth way is to add a list of SrcSpan to the annotation for the parent structure of the list, simply tracking the comma positions. This will make working with the annotations complicated though.<br><br><br></div>I am currently proceeding with option 2, but would appreciate some comment on whether this is the best approach to take.  <br><br>Option 2 will allow the AST to capture the extra commas in record constructors, as suggested by SPJ in the debate on that feature.<br><br><br></div>Regards<br></div>  Alan<br><div><div><br></div></div></div>