Capturing commas in Api Annotations (D297)
Alan & Kim Zimmerman
alan.zimm at gmail.com
Thu Oct 9 16:07:09 UTC 2014
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 <carter.schonwald at gmail.com
> One small question I have is this: why's it called a comma list?
> On Oct 8, 2014 12:33 PM, "Alan & Kim Zimmerman" <alan.zimm at gmail.com>
>> 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
>> 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
>> This is the current approach I am taking, modelled on the OrdList
>> implementation, but with an extra constructor to capture the separator
>> 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.
>> ghc-devs mailing list
>> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs