It is a structure proposed to capture extra commas in record declarations, which I have abused for use here.
I have subsequently realised that I am using it to capture EVERY comma, and sometimes semicolons, so its naming is even worse for my use. Hence I am pretty sure it is something that should change, but I am not sure whether it should change in the hsSyn or be captured in annotations, or what the best mixture between those two is. On Thu, Oct 9, 2014 at 6:03 PM, Carter Schonwald <[email protected] > wrote: > One small question I have is this: why's it called a comma list? > On Oct 8, 2014 12:33 PM, "Alan & Kim Zimmerman" <[email protected]> > wrote: > >> 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. >> >> The question I have is how to capture commas and semicolons in lists of >> items. >> >> There are at least three ways of doing this >> >> 1. Make sure each of the items is Located, and add the possible comma >> location to the annotation structure for it. >> >> 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. >> >> >> 2. Introduce a new hsSyn structure to explicitly capture comma-separated >> lists. >> >> This is the current approach I am taking, modelled on the OrdList >> implementation, but with an extra constructor to capture the separator >> location. >> >> Thus >> >> ``` >> data HsCommaList a >> = Empty >> | Cons a (HsCommaList a) >> | ExtraComma SrcSpan (HsCommaList a) >> -- ^ We need a SrcSpan for the annotation >> | Snoc (HsCommaList a) a >> | Two (HsCommaList a) -- Invariant: non-empty >> (HsCommaList a) -- Invariant: non-empty >> ``` >> >> >> 3. Change the lists to be of type `[Either SrcSpan a]` to explicitly >> capture the comma locations in the list. >> >> >> 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. >> >> >> I am currently proceeding with option 2, but would appreciate some >> comment on whether this is the best approach to take. >> >> Option 2 will allow the AST to capture the extra commas in record >> constructors, as suggested by SPJ in the debate on that feature. >> >> >> Regards >> Alan >> >> >> _______________________________________________ >> ghc-devs mailing list >> [email protected] >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >>
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
