Capturing commas in Api Annotations (D297)

[Alan & Kim Zimmerman]

I have just thought of a much simpler way of doing this.

The approach I am following [1] allows annotations indexed by SrcSpan and
annotation type. There is nothing to stop a given SrcSpan from having
multiple annotations, provided they are each fof a different type.

So when a Located element is in a list, we add a AnnListSeparator
annotation to the SrcSpan as well as the one specific to the type.

This means the whole HsCommaList thing can go away, and the annotations are
still easy to use.

[1] https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations#design

Alan

On Thu, Oct 9, 2014 at 6:07 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com>
wrote:

> 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> 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" <alan.zimm at gmail.com>
>> 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
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141010/f8f2c369/attachment.html>