Capturing commas in Api Annotations (D297)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Capturing commas in Api Annotations (D297)

Alan & Kim Zimmerman
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141008/95d9cb3b/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Capturing commas in Api Annotations (D297)

Carter Schonwald
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/20141009/f211244d/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Capturing commas in Api Annotations (D297)

Alan & Kim Zimmerman
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/20141009/526bcdb0/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

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>