Re: Proposal process status

[Carter Schonwald]

On Wednesday, July 20, 2016, Ben Gamari  wrote:

> Yuras Shumovich > writes:
>
> > Looks like reddit is a wrong place, so I'm replicating my comment here:
> >
> Thanks for your comments Yuras!
>
> >>   * Do you feel the proposed process is an improvement over the
> >> status quo?
> >
> > Yes, definitely. The existing process is too vague, so formalizing it
> > is a win in any case.
> >
> Good to hear.
>
> >>   * What would you like to see changed in the proposed process, if
> >> anything?
> >
> > The proposed process overlaps with the Language Committee powers. In
> > theory the Committee works on language standard, but de facto Haskell
> > is GHC/Haskell and GHC/Haskell is Haskell. Adding new extension to GHC
> > adds new extension to Haskell. So I'd like the process to enforce
> > separation between experimental extensions (not recommended in
> > production code) and language improvements. I'd like the process to
> > specify how the GHC Committee is going to communicate and share powers
> > with the Language Committee.
> >
> To clarify I think Language Committee here refers to the Haskell Prime
> committee, right?
>
> I think these two bodies really do serve different purposes.
> Historically the Haskell Prime committee has been quite conservative in
> the sorts of changes that they standardized; as far as I know almost all
> of them come from a compiler. I would imagine that the GHC Committee
> would be a gate-keeper for proposals entering GHC and only some time
> later, when the semantics and utility of the extension are
> well-understood, would the Haskell Prime committee consider introducing
> it to the Report. As far as I understand it, this is historically how
> things have worked in the past, and I don't think this new process would
> change that.
>
> Of course, let me know if I'm off-base here.


As one of the 20 members of the Haskell (Prime) 2020 committee id like to
interject on this front: the preliminary discussions the committee has had
thus far had a clear agreement that we shall aim to be a bit more
progressive about what shall be included in the standard. The main bar will
be the extent to which features or capabilities can be articulated without
over specifying implementation details and can tractably have compatible
but different compilers for the standard.

  I think some of the other prime committee members can articulate this a
bit better than I, so don't hold me to this precise phrasing ;)




>
> Cheers,
>
> - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Should we send Travis messages to ghc-builds?

[Ben Gamari]

Ben Gamari  writes:

> [ Unknown signature status ]
>
> Hello everyone,
>
> While picking up the pieces from a failed merge today I realized that we
> currently spend a fair bit of carbon footprint and CPU cycles making
> Travis test GHC yet the results of these tests aren't pushed anywhere.
>
> Would anyone object to having Travis push notifications of changes in
> red/green state to ghc-bui...@haskell.org? Perhaps this will allow some
> of us to react more quickly to regressions.
>
Actually Thomas points out that we indeed used to do this and yet
stopped because it meant that users would fork the repository, enable
Travis build on their fork, and then inadvertantly spam the list. So,
perhaps we shouldn't do this.

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Should we send Travis messages to ghc-builds?

[Ben Gamari]

Hello everyone,

While picking up the pieces from a failed merge today I realized that we
currently spend a fair bit of carbon footprint and CPU cycles making
Travis test GHC yet the results of these tests aren't pushed anywhere.

Would anyone object to having Travis push notifications of changes in
red/green state to ghc-bui...@haskell.org? Perhaps this will allow some
of us to react more quickly to regressions.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal process status

[Niklas Larsson]

> 20 juli 2016 kl. 19:38 skrev amin...@gmail.com:
> 
> 
> 
>> El 20 jul 2016, a las 12:45, Ben Gamari  escribió:
>> 
>> Iavor Diatchki  writes:
>> 
>>> Hello Ben,
>>> 
>>> I posted this when you originally asked for feed-back, but perhaps it
>>> got buried among the rest of the e-mails.
>> Indeed it seems that way. Sorry about that!
>> 
>>> I think the proposal sounds fairly reasonable, but it is hard to say how
>>> well it will work in practice until we try it, and we should be ready to
>>> change it if needs be.
>> Right. I fully expect that we will have to iterate on it.
>> 
>>> Some clarifying questions on the intended process:
>>> 1.  After submitting the initial merge request, is the person making the
>>> proposal to wait for any kind of acknowledgment, or just move on to step 2?
>> The discussion phase can happen asynchronously from any action by the
>> Committee. Of course, the Committee should engauge in discussion early,
>> but I don't think any sort of acknowledgement is needed. An open pull
>> request should be taken to mean "let's discuss this idea."
>> 
>>> 2. Is the discussion going to happen on one of the mailing lists, if so
>>> which?   Is it the job of the proposing person to involve/notify the
>>> committee about the discussion?  If so, how are they to find out who is on
>>> the committee?
>> 
>> The proposed process places the discussion in a pull request. The idea
>> here is to use well-understood and widely-used code review tools to
>> faciliate the conversation.
> 
> This part runs strongly against the grain of what I'd prefer: email is 
> lightweight, decentralized, standard, and has many clients. We can read 
> discussion of Haskell proposals any way we like. Github on the other hand 
> only allows us to read issues by going to Github, and using whatever 
> interface Github has given us (which personally I find very annoying, esp. on 
> mobile). In addition, reading proposals offline becomes very difficult. Many 
> of us read discussion when commuting, where, e.g. in NYC, there isn't cell 
> service.
> 
> For reviewing code that implements a proposal, I'm a lot more flexible 
> (although again I'm not a fan of Github)
> 
> For the people who like having history tracked with git: gitit is a 
> possibility, and is written in Haskell.
> 
> Tom
> 

It's possible both follow and contribute to issues in a github repo via email. 
I do it all the time for Idris.

// Niklas

> 
> 
>> The Committee members will be notified of the open pull request by the
>> usual event notification mechanism (e.g. in GitHub one can subscribe to
>> a repository).
>> 
>>> 3. How does one actually perform step 3, another pull request or simply
>>> an e-mail to someone?
>> The opening of the pull request would mark the beginning of the
>> discussion period. When the author feels that the discussion has come to
>> something of a conclusion, they will request that the GHC Committee
>> consider the proposal for acceptable by leaving a comment on the pull
>> request.
>> 
>>> Typo: two separate bullets in the proposal are labelled as 4.
>> I believe this should be fixed now. Thanks!
>> 
>> Cheers,
>> 
>> - Ben
>> 
>> ___
>> Glasgow-haskell-users mailing list
>> glasgow-haskell-us...@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> ___
> Glasgow-haskell-users mailing list
> glasgow-haskell-us...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal process status

[Ben Gamari]

Iavor Diatchki  writes:

> Hello Ben,
>
> I posted this when you originally asked for feed-back, but perhaps it
> got buried among the rest of the e-mails.
>
Indeed it seems that way. Sorry about that!

> I think the proposal sounds fairly reasonable, but it is hard to say how
> well it will work in practice until we try it, and we should be ready to
> change it if needs be.
>
Right. I fully expect that we will have to iterate on it.

> Some clarifying questions on the intended process:
>1.  After submitting the initial merge request, is the person making the
> proposal to wait for any kind of acknowledgment, or just move on to step 2?
>
The discussion phase can happen asynchronously from any action by the
Committee. Of course, the Committee should engauge in discussion early,
but I don't think any sort of acknowledgement is needed. An open pull
request should be taken to mean "let's discuss this idea."

>2. Is the discussion going to happen on one of the mailing lists, if so
> which?   Is it the job of the proposing person to involve/notify the
> committee about the discussion?  If so, how are they to find out who is on
> the committee?

The proposed process places the discussion in a pull request. The idea
here is to use well-understood and widely-used code review tools to
faciliate the conversation.

The Committee members will be notified of the open pull request by the
usual event notification mechanism (e.g. in GitHub one can subscribe to
a repository).

>3. How does one actually perform step 3, another pull request or simply
> an e-mail to someone?
>
The opening of the pull request would mark the beginning of the
discussion period. When the author feels that the discussion has come to
something of a conclusion, they will request that the GHC Committee
consider the proposal for acceptable by leaving a comment on the pull
request.

> Typo: two separate bullets in the proposal are labelled as 4.
>
I believe this should be fixed now. Thanks!

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal process status

[Ben Gamari]

Yuras Shumovich  writes:

> Looks like reddit is a wrong place, so I'm replicating my comment here:
>
Thanks for your comments Yuras!

>>   * Do you feel the proposed process is an improvement over the
>> status quo?
>
> Yes, definitely. The existing process is too vague, so formalizing it
> is a win in any case.
>
Good to hear.

>>   * What would you like to see changed in the proposed process, if
>> anything?
>
> The proposed process overlaps with the Language Committee powers. In
> theory the Committee works on language standard, but de facto Haskell
> is GHC/Haskell and GHC/Haskell is Haskell. Adding new extension to GHC
> adds new extension to Haskell. So I'd like the process to enforce
> separation between experimental extensions (not recommended in
> production code) and language improvements. I'd like the process to
> specify how the GHC Committee is going to communicate and share powers
> with the Language Committee.
>
To clarify I think Language Committee here refers to the Haskell Prime
committee, right?

I think these two bodies really do serve different purposes.
Historically the Haskell Prime committee has been quite conservative in
the sorts of changes that they standardized; as far as I know almost all
of them come from a compiler. I would imagine that the GHC Committee
would be a gate-keeper for proposals entering GHC and only some time
later, when the semantics and utility of the extension are
well-understood, would the Haskell Prime committee consider introducing
it to the Report. As far as I understand it, this is historically how
things have worked in the past, and I don't think this new process would
change that.

Of course, let me know if I'm off-base here.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal process status

[Iavor Diatchki]

Hello Ben,

I posted this when you originally asked for feed-back, but perhaps it
got buried among the rest of the e-mails.

I think the proposal sounds fairly reasonable, but it is hard to say how
well it will work in practice until we try it, and we should be ready to
change it if needs be.

Some clarifying questions on the intended process:
   1.  After submitting the initial merge request, is the person making the
proposal to wait for any kind of acknowledgment, or just move on to step 2?
   2. Is the discussion going to happen on one of the mailing lists, if so
which?   Is it the job of the proposing person to involve/notify the
committee about the discussion?  If so, how are they to find out who is on
the committee?
   3. How does one actually perform step 3, another pull request or simply
an e-mail to someone?

Typo: two separate bullets in the proposal are labelled as 4.

Cheers,
-Iavor

On Wed, Jul 20, 2016 at 2:36 AM, Ben Gamari  wrote:

>
> Hello everyone,
>
> As you hopefully know, a few weeks ago we proposed a new process [1] for
> collecting, discussing, and deciding upon changes to GHC and its Haskell
> superset. While we have been happy to see a small contingent of
> contributors join the discussion, the number is significantly smaller
> than the set who took part in the earlier Reddit discussions.
>
> In light of this, we are left a bit uncertain of how to proceed. So,
> we would like to ask you to let us know your feelings regarding the
> proposed process:
>
>   * Do you feel the proposed process is an improvement over the status
> quo?
>
>   * Why? (this needn't be long, just a sentence hitting the major points)
>
>   * What would you like to see changed in the proposed process, if
> anything?
>
> That's all. Again, feel free to reply either on the GitHub pull request
> [1] or this thread if you would prefer. Your response needn't be long;
> we just want to get a sense of how much of the community feels that 1)
> this effort is worth undertaking, and 2) that the proposal before us is
> in fact an improvement over the current state of affairs.
>
> Thanks for your help!
>
> Cheers,
>
> - Ben
>
>
> [1] https://github.com/ghc-proposals/ghc-proposals/pull/1
>
> ___
> Glasgow-haskell-users mailing list
> glasgow-haskell-us...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

git.haskell.org slow

[Simon Peyton Jones via ghc-devs]

Is it my imagination or is git.haskell.org really slow at the moment?
SImion
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Note [Api annotations]

[Alan & Kim Zimmerman]

Hopefully at a future date they will be a part of the AST itself, so this
will be clearer.

In reality, looking at Parser.y is not enough, as there are some workings
in RdrHsSyn.hs too, and the process of attachment in Parser.y is sometimes
quite complex.

Basically the best reference is indeed ghc-exactprint, being an application
that expressly makes use of all of them.

Alan

On Wed, Jul 20, 2016 at 2:01 PM, Matthew Pickering <
matthewtpicker...@gmail.com> wrote:

> On Wed, Jul 20, 2016 at 12:22 PM, Ben Gamari  wrote:
> > Matthew Pickering  writes:
> >
> >> These comments are meant to indicate which annotations each AST
> >> fragment has. However, they are rarely kept up to date and ultimately
> >> not that useful. If someone wants to
> >> know then it is easier to look at the `Annotate` module in
> >> `ghc-exactprint`where this information also exists programatically.
> >>
> > Hmm, the fact that this module is outside of GHC is a bit unfortunate.
> > If I'm looking at a random GHC commit from a year ago how am I to know
> > which annotations I can expect? I guess the testsuite?
>
> The only reliable way is to look at `Parser.y`.
>
> >
> > Cheers,
> >
> > - Ben
> >
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal process status

[Alan & Kim Zimmerman]

I think the most important thing is to be able to point to a designated
point where discussions must take place. This means if anything comes up
elsewhere it can be routed there to be "official".

Alan

On Wed, Jul 20, 2016 at 1:42 PM, Yuras Shumovich 
wrote:

>
> Looks like reddit is a wrong place, so I'm replicating my comment here:
>
> On Wed, 2016-07-20 at 11:36 +0200, Ben Gamari wrote:
> > Hello everyone,
> >
> > As you hopefully know, a few weeks ago we proposed a new process [1]
> > for
> > collecting, discussing, and deciding upon changes to GHC and its
> > Haskell
> > superset. While we have been happy to see a small contingent of
> > contributors join the discussion, the number is significantly smaller
> > than the set who took part in the earlier Reddit discussions.
> >
> > In light of this, we are left a bit uncertain of how to proceed. So,
> > we would like to ask you to let us know your feelings regarding the
> > proposed process:
> >
> >   * Do you feel the proposed process is an improvement over the
> > status
> > quo?
>
> Yes, definitely. The existing process is too vague, so formalizing it
> is a win in any case.
>
>
> >
> >   * Why? (this needn't be long, just a sentence hitting the major
> > points)
> >
> >   * What would you like to see changed in the proposed process, if
> > anything?
>
>
> The proposed process overlaps with the Language Committee powers. In
> theory the Committee works on language standard, but de facto Haskell
> is GHC/Haskell and GHC/Haskell is Haskell. Adding new extension to GHC
> adds new extension to Haskell. So I'd like the process to enforce
> separation between experimental extensions (not recommended in
> production code) and language improvements. I'd like the process to
> specify how the GHC Committee is going to communicate and share powers
> with the Language Committee.
>
> Thanks,
> Yuras.
>
> >
> > That's all. Again, feel free to reply either on the GitHub pull
> > request
> > [1] or this thread if you would prefer. Your response needn't be
> > long;
> > we just want to get a sense of how much of the community feels that
> > 1)
> > this effort is worth undertaking, and 2) that the proposal before us
> > is
> > in fact an improvement over the current state of affairs.
> >
> > Thanks for your help!
> >
> > Cheers,
> >
> > - Ben
> >
> >
> > [1] https://github.com/ghc-proposals/ghc-proposals/pull/1
> > ___
> > Glasgow-haskell-users mailing list
> > glasgow-haskell-us...@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-user
> > s
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Note [Api annotations]

[Matthew Pickering]

On Wed, Jul 20, 2016 at 12:22 PM, Ben Gamari  wrote:
> Matthew Pickering  writes:
>
>> These comments are meant to indicate which annotations each AST
>> fragment has. However, they are rarely kept up to date and ultimately
>> not that useful. If someone wants to
>> know then it is easier to look at the `Annotate` module in
>> `ghc-exactprint`where this information also exists programatically.
>>
> Hmm, the fact that this module is outside of GHC is a bit unfortunate.
> If I'm looking at a random GHC commit from a year ago how am I to know
> which annotations I can expect? I guess the testsuite?

The only reliable way is to look at `Parser.y`.

>
> Cheers,
>
> - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal process status

[Yuras Shumovich]

Looks like reddit is a wrong place, so I'm replicating my comment here:

On Wed, 2016-07-20 at 11:36 +0200, Ben Gamari wrote:
> Hello everyone,
> 
> As you hopefully know, a few weeks ago we proposed a new process [1]
> for
> collecting, discussing, and deciding upon changes to GHC and its
> Haskell
> superset. While we have been happy to see a small contingent of
> contributors join the discussion, the number is significantly smaller
> than the set who took part in the earlier Reddit discussions.
> 
> In light of this, we are left a bit uncertain of how to proceed. So,
> we would like to ask you to let us know your feelings regarding the
> proposed process:
> 
>   * Do you feel the proposed process is an improvement over the
> status
> quo?

Yes, definitely. The existing process is too vague, so formalizing it
is a win in any case.


> 
>   * Why? (this needn't be long, just a sentence hitting the major
> points)
> 
>   * What would you like to see changed in the proposed process, if
> anything?


The proposed process overlaps with the Language Committee powers. In
theory the Committee works on language standard, but de facto Haskell
is GHC/Haskell and GHC/Haskell is Haskell. Adding new extension to GHC
adds new extension to Haskell. So I'd like the process to enforce
separation between experimental extensions (not recommended in
production code) and language improvements. I'd like the process to
specify how the GHC Committee is going to communicate and share powers
with the Language Committee.

Thanks,
Yuras.

> 
> That's all. Again, feel free to reply either on the GitHub pull
> request
> [1] or this thread if you would prefer. Your response needn't be
> long;
> we just want to get a sense of how much of the community feels that
> 1)
> this effort is worth undertaking, and 2) that the proposal before us
> is
> in fact an improvement over the current state of affairs.
> 
> Thanks for your help!
> 
> Cheers,
> 
> - Ben
> 
> 
> [1] https://github.com/ghc-proposals/ghc-proposals/pull/1
> ___
> Glasgow-haskell-users mailing list
> glasgow-haskell-us...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-user
> s
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Note [Api annotations]

[Ben Gamari]

Matthew Pickering  writes:

> These comments are meant to indicate which annotations each AST
> fragment has. However, they are rarely kept up to date and ultimately
> not that useful. If someone wants to
> know then it is easier to look at the `Annotate` module in
> `ghc-exactprint`where this information also exists programatically.
>
Hmm, the fact that this module is outside of GHC is a bit unfortunate.
If I'm looking at a random GHC commit from a year ago how am I to know
which annotations I can expect? I guess the testsuite?

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal process status

[Thomas Miedema]

>
>   * What would you like to see changed in the proposed process, if
> anything?
>

*Simon Peyton Jones as Benevolent Dictator For Life (BDFL)*

If the BDFL had made a simple YES/NO decision on ShortImports [1] and
ArgumentDo [2], we wouldn't be here talking about process proposals,
Anthony wouldn't be mad, everything would be fine. We don't need another
Haskell committee.

* Keep using Trac for proposals, but use the description field of a ticket
for the specification, instead of separate wiki page.

* Add better filtering possibilities to Trac (say someone wants to only
subscribe to tickets where syntax extensions are discussed). Adding better
filtering possibilities will also benefit bug fixers (say someone wants to
only subscribe to bugs on Windows or with keyword=PatternSynonyms).

* Don't let hotly debated feature requests go without a resolution.

[0] https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
[1] https://ghc.haskell.org/trac/ghc/ticket/10478
[2] https://ghc.haskell.org/trac/ghc/ticket/10843
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Note [Api annotations]

[Matthew Pickering]

These comments are meant to indicate which annotations each AST
fragment has. However, they are rarely kept up to date and ultimately
not that useful. If someone wants to
know then it is easier to look at the `Annotate` module in
`ghc-exactprint`where this information also exists programatically.

On Wed, Jul 20, 2016 at 9:24 AM, Ömer Sinan Ağacan  wrote:
> I see some weird comments like
>
> --  - 'ApiAnnotation.AnnKeywordId' : 'ApiAnnotation.AnnOpen',
> --  'ApiAnnotation.AnnVbar','ApiAnnotation.AnnComma',
> --  'ApiAnnotation.AnnClose'
>
> -- For details on above see note [Api annotations] in ApiAnnotation
>
> in some files, but Note [Api annotations] in compiler/parser/ApiAnnotation.hs
> doesn't say anything about those comments. Can someone update the note to
> explain what are those comments for?
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Proposal process status

[Ben Gamari]

Hello everyone,

As you hopefully know, a few weeks ago we proposed a new process [1] for
collecting, discussing, and deciding upon changes to GHC and its Haskell
superset. While we have been happy to see a small contingent of
contributors join the discussion, the number is significantly smaller
than the set who took part in the earlier Reddit discussions.

In light of this, we are left a bit uncertain of how to proceed. So,
we would like to ask you to let us know your feelings regarding the
proposed process:

  * Do you feel the proposed process is an improvement over the status
quo?

  * Why? (this needn't be long, just a sentence hitting the major points)

  * What would you like to see changed in the proposed process, if
anything?

That's all. Again, feel free to reply either on the GitHub pull request
[1] or this thread if you would prefer. Your response needn't be long;
we just want to get a sense of how much of the community feels that 1)
this effort is worth undertaking, and 2) that the proposal before us is
in fact an improvement over the current state of affairs.

Thanks for your help!

Cheers,

- Ben


[1] https://github.com/ghc-proposals/ghc-proposals/pull/1


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Note [Api annotations]

[Ömer Sinan Ağacan]

I see some weird comments like

--  - 'ApiAnnotation.AnnKeywordId' : 'ApiAnnotation.AnnOpen',
--  'ApiAnnotation.AnnVbar','ApiAnnotation.AnnComma',
--  'ApiAnnotation.AnnClose'

-- For details on above see note [Api annotations] in ApiAnnotation

in some files, but Note [Api annotations] in compiler/parser/ApiAnnotation.hs
doesn't say anything about those comments. Can someone update the note to
explain what are those comments for?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs