addTopDecls restrictions

[Richard Eisenberg]

Hi Geoff,

The TH addTopDecls function is restricted to only a few kinds of declarations 
(functions, mostly). This set has been expanded in #10486 
(https://ghc.haskell.org/trac/ghc/ticket/10486). Do you remember why the set of 
allowed declarations is restricted? It looks to me like any declaration would 
be OK.

Thanks!
Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: accept pull requests on GitHub

[Michael Smith]

On Wed, Sep 2, 2015 at 9:41 PM, Austin Seipp  wrote:

>   - Make it clear what we expect of contributors. I feel like a lot of
> this could be explained by having a 5 minute drive-by guide for
> patches, and then a longer 10-minute guide about A) How to style
> things, B) How to format your patches if you're going to contribute
> regularly, C) Why it is this way, and D) finally links to all the
> other things you need to know. People going into Phabricator expecting
> it to behave like GitHub is a problem (more a cultural problem IMO but
> that's another story), and if this can't be directly fixed, the best
> thing to do is make it clear why it isn't.
>

This is tangential to the issue of the code review system, and I don't want
to
derail the discussion here, but if you're talking about a drive-by guide for
patches, I'd add E) straightforward instructions on how to get GHC building
*fast* for development. A potential contributor won't even reach the patch
submission stage if they can't get the build system set up properly, and the
current documentation here is spread out and somewhat intimidating for a
newcomer.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: HEADS UP: interface file format change, full rebuild required

[Austin Seipp]

A long time coming. Congratulations!

On Wed, Sep 2, 2015 at 10:57 PM, Jan Stolarek  wrote:
> I just pushed injective type families patch, which changes interface file 
> format. Full rebuild of
> GHC is required after you pull.
>
> Jan
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: accept pull requests on GitHub

[Austin Seipp]

(JFYI: I hate to announce my return with a giant novel of
negative-nancy-ness about a proposal that just came up. I'm sorry
about this!)

TL;DR: I'm strongly -1 on this, because I think it introduces a lot of
associated costs for everyone, the benefits aren't really clear, and I
think it obscures the real core issue about "how do we get more
contributors" and how to make that happen. Needless to say, GitHub
does not magically solve both of these AFAICS.

As is probably already widely known, I'm fairly against GitHub because
I think at best its tools are mediocre and inappropriate for GHC - but
I also don't think this proposal or the alternatives stemming from it
are very good, and that it reduces visibility of the real, core
complaints about what is wrong. Some of those problems may be with
Phabricator, but it's hard to sort the wheat from the chaff, so to
speak.

For one, having two code review tools of any form is completely
bonkers, TBQH. This is my biggest 'obvious' blocker. If we're going to
switch, we should just switch. Having to have people decide how to
contribute with two tools is as crazy as having two VCSs and just a
way of asking people to get *more* confused, and have us answer more
questions. That's something we need to avoid.

For the same reason, I'm also not a fan of 'use third party thing to
augment other thing to remove its deficiencies making it OK', because
the problem is _it adds surface area_ and other problems in other
cases. It is a solution that should be considered a last resort,
because it is a logical solution that applies to everything. If we
have a bot that moves GH PRs into Phab and then review them there, the
surface area of what we have to maintain and explain has suddenly
exploded: because now instead of 1 thing we have 3 things (GH, Phab,
bot) and the 3 interactions between them, for a multiplier of *six*
things we have to deal with. And then we use reviewable,io, because GH
reviews are terrible, adding a 4th mechanism? It's rube goldberg-ian.
We can logically 'automate' everything in all ways to make all
contributors happy, but there's a real *cognitive* overhead to this
and humans don't scale as well as computers do. It is not truly
'automated away' if the cognitive burden is still there.

I also find it extremely strange to tell people "By the way, this
method in which you've contributed, as was requested by community
members, is actually a complete proxy for the real method of
contributing, you can find all your imported code here". How is this
supposed to make contribution *easier* as opposed to just more
confusing? Now you've got the impression you're using "the real thing"
when in reality it's shoved off somewhere else to have the nitpicking
done. Just using Phabricator would be less complicated, IMO, and much
more direct.

The same thing goes for reviewable.io. Adding it as a layer over
GitHub just makes the surface area larger, and puts less under our
control. And is it going to exist in the same form in 2 or 3 years?
Will it continue to offer the same tools, the same workflows that we
"like", and what happens when we hit a wall? It's easy to say
"probably" or "sure" to all this, until we hit something we dislike
and have no possibility of fixing.

And once you do all this, BTW, you can 'never go back'. It seems so
easy to just say 'submit pull requests' once and nothing else, right?
Wrong. Once you commit to that infrastructure, it is *there* and
simply taking it out from under the feet of those using it is not only
unfortunate, it is *a huge timesink to undo it all*. Which amounts to
it never happening. Oh, but you can import everything elsewhere! The
problem is you *can't* import everything, but more importantly you
can't *import my memories in another way*, so it's a huge blow to
contributors to ask them about these mental time sinks, then to forget
them all. And as your project grows, this becomes more of a memory as
you made a first and last choice to begin with.

Phabricator was 'lucky' here because it had the gateway into being the
first review tool for us. But that wasn't because it was *better* than
GitHub. It was because we were already using it, and it did not
interact badly with our other tools or force us to compromise things -
so the *cost* was low. The cost is immeasurably higher by default
against GitHub because of this, at least to me. That's just how it is
sometimes.

Keep in mind there is a cost to everything and how you fix it. GitHub
is not a simple patch to add a GHC feature. It is a question that
fundamentally concerns itself with the future of the project for a
long time. The costs must be analyzed more aggressively. Again,
Phabricator had 'first child' preferential treatment. That's not
something we can undo now.

I know this sounds like a lot of ad hoc mumbo jumbo, but please bear
with me: we need to identify the *root issue* here to fix it.
Otherwise we will pay for the costs of an improper fix for a long
time, and we are going to ke

HEADS UP: interface file format change, full rebuild required

[Jan Stolarek]

I just pushed injective type families patch, which changes interface file 
format. Full rebuild of 
GHC is required after you pull.

Jan

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

Re: [Haskell-cafe] Foreign calls and periodic alarm signals

[Brandon Allbery]

On Wed, Sep 2, 2015 at 7:56 PM, Donn Cave  wrote:

> Sure are, though I don't know of any that have been identified so
> directly as yours.  I mean it sounds like you know where and how it's
> breaking.  Usually we just know something's dying on an interrupt and
> then think to try turning off the signal barrage.  It's interesting
> that you're getting a stall instead, due to an EINTR loop.
>

network is moderately infamous for (formerly?) using unsafe calls that
block

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Foreign calls and periodic alarm signals

[Phil Ruffwind]

TL;DR: Does 'foreign import safe' silence the periodic alarm signals?

I received a report on this rather strange bug in 'directory':

https://github.com/haskell/directory/issues/35#issuecomment-136890912

I've concluded based on the dtruss log that it's caused by the timer
signal that the GHC runtime emits.  Somewhere inside the guts of
'realpath' on Mac OS X, there is a function that does the moral
equivalent of:

while (statfs64(…) && errno == EINTR);

On a slow filesystem like SSHFS, this can cause a permanent hang from
the barrage of signals.

The reporter found that using 'foreign import safe' mitigates the
issue.  What I'm curious mainly is that: is something that the GHC
runtime guarantees -- is using 'foreign import safe' assured to turn
off the periodic signals for that thread?

I tried reading this article [1], which seems to be the only
documentation I could find about this, and it didn't really go into
much depth about them.  (I also couldn't find any info about how
frequently they occur, on which threads they occur, or which specific
signal it uses.)

I'm also concerned whether there are other foreign functions out in
the wild that could suffer the same bug, but remain hidden because
they normally complete before the next alarm signal.

[1]: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: accept pull requests on GitHub

[Niklas Hambüchen]

On 02/09/15 22:42, Kosyrev Serge wrote:
> As a wild idea -- did anyone look at /Gitlab/ instead?

Hi, yes. It does not currently have a sufficient review functionality
(cannot handle multiple revisions easily).

On 02/09/15 20:51, Simon Marlow wrote:
> It might feel better
> for the author, but discovering what changed between two branches of
> multiple commits on github is almost impossible.

I disagree with the first part of this: When the UI of the review tool
is good, it is easy to follow. But there's no open-source implementation
of that around.

I agree that it is not easy to follow on Github.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Testsuite and validate changes

[Thomas Miedema]

All,

I made the following changes today:

* `make accept` now runs all tests for a single way (instead of all ways)
* `make test` now runs all tests for a single way (instead of all ways)
* `./validate` now runs all tests for a single way (instead of skipping
some tests)
* Phabricator now runs all tests for a single way (instead of skipping some
tests)

You can run `make slowtest` in the root directory, or `make slow` in the
testsuite directory, to get the old behavior of `make test` back.

More information:
*
https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running#Speedsettings
* https://phabricator.haskell.org/D1178
* Note [validate and testsuite speed] in the toplevel Makefile

Thanks,
Thomas
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: accept pull requests on GitHub

[Kosyrev Serge]

Simon Marlow  writes:
> On 01/09/2015 11:34, Thomas Miedema wrote:
>> Hello all,
>>
>> my arguments against Phabricator are here:
>> https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator.
>
> Thanks for taking the time to summarize all the issues.
>
> Personally, I think github's support for code reviews is too weak to 
> recommend it
> over Phabricator.  The multiple-email problem is a killer all by itself.

As a wild idea -- did anyone look at /Gitlab/ instead?

I didn't look into its review functionality to any meaninful degree, but:

 - it largely tries to replicate the Github workflow
 - Gitlab CE is open source
 - it evolves fairly quickly

-- 
с уважениeм / respectfully,
Косырев Серёга
--
“And those who were seen dancing were thought to be insane
 by those who could not hear the music.”
 – Friedrich Wilhelm Nietzsche
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Shared data type for extension flags

[Michael Smith]

I don't know about the entire AST. GHC's AST contains a lot of complexity
that one wouldn't want to expose at the TH level. And the separation allows
GHC to change the internal AST around while maintaining a stable interface
for packages depending on TH.

That said, there are some bits that I could see being shared. Fixity and
Strict from TH come to mind.

On Wed, Sep 2, 2015, 11:39 Alan & Kim Zimmerman  wrote:

> Would this be a feasible approach for harmonising the AST between GHC and
> TH too?
>
> Alan
> On 2 Sep 2015 09:27, "Michael Smith"  wrote:
>
>> The package description for that is "The GHC compiler's view of the GHC
>> package database format", and this doesn't really have to do with the
>> package database format. Would it be okay to put this in there anyway?
>>
>> On Wed, Sep 2, 2015, 07:33 Simon Peyton Jones 
>> wrote:
>>
>>> we already have such a shared library, I think: bin-package-db.  would
>>> that do?
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of 
>>> *Michael
>>> Smith
>>> *Sent:* 02 September 2015 09:21
>>> *To:* Matthew Pickering
>>> *Cc:* GHC developers
>>> *Subject:* Re: Shared data type for extension flags
>>>
>>>
>>>
>>> That sounds like a good approach. Are there other things that would go
>>> nicely
>>> in a shared package like this, in addition to the extension data type?
>>>
>>>
>>>
>>> On Wed, Sep 2, 2015 at 1:00 AM, Matthew Pickering <
>>> matthewtpicker...@gmail.com> wrote:
>>>
>>> Surely the easiest way here (including for other tooling - ie
>>> haskell-src-exts) is to create a package which just provides this
>>> enumeration. GHC, cabal, th, haskell-src-exts and so on then all
>>> depend on this package rather than creating their own enumeration.
>>>
>>>
>>> On Wed, Sep 2, 2015 at 9:47 AM, Michael Smith 
>>> wrote:
>>> > #10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the
>>> > capababilty
>>> > to Template Haskell to detect which language extensions enabled.
>>> > Unfortunately,
>>> > since template-haskell can't depend on ghc (as ghc depends on
>>> > template-haskell),
>>> > it can't simply re-export the ExtensionFlag type from DynFlags to the
>>> user.
>>> >
>>> > There is a second data type encoding the list of possible language
>>> > extensions in
>>> > the Cabal package, in Language.Haskell.Extension [3]. But
>>> template-haskell
>>> > doesn't already depend on Cabal, and doing so seems like it would cause
>>> > difficulties, as the two packages can be upgraded separately.
>>> >
>>> > So adding this new feature to Template Haskell requires introducing a
>>> > *third*
>>> > data type for language extensions. It also requires enumerating this
>>> full
>>> > list
>>> > in two more places, to convert back and forth between the TH Extension
>>> data
>>> > type
>>> > and GHC's internal ExtensionFlag data type.
>>> >
>>> > Is there another way here? Can there be one single shared data type
>>> for this
>>> > somehow?
>>> >
>>> > [1] https://ghc.haskell.org/trac/ghc/ticket/10820
>>> > [2] https://phabricator.haskell.org/D1200
>>> > [3]
>>> >
>>> https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Extension.html
>>> >
>>>
>>> > ___
>>> > 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
>>
>>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: accept pull requests on GitHub

[Tuncer Ayaz]

On Wed, Sep 2, 2015 at 8:51 PM, Simon Marlow  wrote:

> Stacks of commits are hard to reviewers to follow, so making them
> easier might have a detrimental effect on our processes. It might
> feel better for the author, but discovering what changed between two
> branches of multiple commits on github is almost impossible. Instead
> the recommended workflow seems to be to add more commits, which
> makes the history harder to read later.

I've reviewed+merged various big diffs in the form of branches
published as pull requests (on and off GitHub), and being able to see
each change separately with its own commit message was way easier than
one big diff with a summarized message.

If Phabricator would use merge commits, reading multi-commit history,
especially what commits got merged together (aka what branch was
integrated), is easy.

Also, bisecting is more precise without collapsed diffs.

Therefore, I wouldn't say the single-commit collapsed view is the right
choice for all diffs.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: accept pull requests on GitHub

[Simon Marlow]

On 01/09/2015 11:34, Thomas Miedema wrote:

Hello all,

my arguments against Phabricator are here:
https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator.


Thanks for taking the time to summarize all the issues.

Personally, I think github's support for code reviews is too weak to 
recommend it over Phabricator.  The multiple-email problem is a killer 
all by itself.


We can improve the workflow for Phabricator to address some of the 
issues you raise are fixable, such as fixing the base revision to use, 
and ignoring untracked files (these are local settings, I believe).


Stacks of commits are hard to reviewers to follow, so making them easier 
might have a detrimental effect on our processes.  It might feel better 
for the author, but discovering what changed between two branches of 
multiple commits on github is almost impossible.  Instead the 
recommended workflow seems to be to add more commits, which makes the 
history harder to read later.


I have only had to update my arc once.  Is that a big problem?

Cheers
Simon



Some quotes from #ghc to pique your curiosity (there are some 50 more):
  * "is arc broken today?"
  * "arc is a frickin' mystery."
  * "i have a theory that i've managed to create a revision that phab
can't handle."
  * "Diffs just seem to be too expensive to create ... I can't blame
contributors for not wanting to do this for every atomic change"
  * "but seriously, we can't require this for contributing to GHC... the
entry barrier is already high enough"

GitHub has side-by-side diffs
 nowadays, and
Travis-CI can run `./validate --fast` comfortably
.

*Proposal: accept pull requests from contributors on
https://github.com/ghc/ghc.*

Details:
  * use Travis-CI to validate pull requests.
  * keep using the Trac issue tracker (contributors are encouraged to
put a link to their pull-request in the 'Differential Revisions' field).
  * keep using the Trac wiki.
  * in discussions on GitHub, use https://ghc.haskell.org/ticket/1234 to
refer to Trac ticket 1234. The shortcut #1234 only works on Trac itself.
  * keep pushing to git.haskell.org , where the
existing Git receive hooks can do their job keeping tabs, trailing
whitespace and dangling submodule references out, notify Trac and send
emails. Committers close pull-requests manually, just like they do Trac
tickets.
  * keep running Phabricator for as long as necessary.
  * mention that pull requests are accepted on
https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs.

My expectation is that the majority of patches will start coming in via
pull requests, the number of contributions will go up, commits will be
smaller, and there will be more of them per pull request (contributors
will be able to put style changes and refactorings into separate
commits, without jumping through a bunch of hoops).

Reviewers will get many more emails. Other arguments against GitHub are
here: https://ghc.haskell.org/trac/ghc/wiki/WhyNotGitHub.

I probably missed a few things, so fire away.

Thanks,
Thomas



___
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: Shared data type for extension flags

[Alan & Kim Zimmerman]

Would this be a feasible approach for harmonising the AST between GHC and
TH too?

Alan
On 2 Sep 2015 09:27, "Michael Smith"  wrote:

> The package description for that is "The GHC compiler's view of the GHC
> package database format", and this doesn't really have to do with the
> package database format. Would it be okay to put this in there anyway?
>
> On Wed, Sep 2, 2015, 07:33 Simon Peyton Jones 
> wrote:
>
>> we already have such a shared library, I think: bin-package-db.  would
>> that do?
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Michael
>> Smith
>> *Sent:* 02 September 2015 09:21
>> *To:* Matthew Pickering
>> *Cc:* GHC developers
>> *Subject:* Re: Shared data type for extension flags
>>
>>
>>
>> That sounds like a good approach. Are there other things that would go
>> nicely
>> in a shared package like this, in addition to the extension data type?
>>
>>
>>
>> On Wed, Sep 2, 2015 at 1:00 AM, Matthew Pickering <
>> matthewtpicker...@gmail.com> wrote:
>>
>> Surely the easiest way here (including for other tooling - ie
>> haskell-src-exts) is to create a package which just provides this
>> enumeration. GHC, cabal, th, haskell-src-exts and so on then all
>> depend on this package rather than creating their own enumeration.
>>
>>
>> On Wed, Sep 2, 2015 at 9:47 AM, Michael Smith 
>> wrote:
>> > #10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the
>> > capababilty
>> > to Template Haskell to detect which language extensions enabled.
>> > Unfortunately,
>> > since template-haskell can't depend on ghc (as ghc depends on
>> > template-haskell),
>> > it can't simply re-export the ExtensionFlag type from DynFlags to the
>> user.
>> >
>> > There is a second data type encoding the list of possible language
>> > extensions in
>> > the Cabal package, in Language.Haskell.Extension [3]. But
>> template-haskell
>> > doesn't already depend on Cabal, and doing so seems like it would cause
>> > difficulties, as the two packages can be upgraded separately.
>> >
>> > So adding this new feature to Template Haskell requires introducing a
>> > *third*
>> > data type for language extensions. It also requires enumerating this
>> full
>> > list
>> > in two more places, to convert back and forth between the TH Extension
>> data
>> > type
>> > and GHC's internal ExtensionFlag data type.
>> >
>> > Is there another way here? Can there be one single shared data type for
>> this
>> > somehow?
>> >
>> > [1] https://ghc.haskell.org/trac/ghc/ticket/10820
>> > [2] https://phabricator.haskell.org/D1200
>> > [3]
>> >
>> https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Extension.html
>> >
>>
>> > ___
>> > 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
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Shared data type for extension flags

[Michael Smith]

The package description for that is "The GHC compiler's view of the GHC
package database format", and this doesn't really have to do with the
package database format. Would it be okay to put this in there anyway?

On Wed, Sep 2, 2015, 07:33 Simon Peyton Jones  wrote:

> we already have such a shared library, I think: bin-package-db.  would
> that do?
>
>
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Michael
> Smith
> *Sent:* 02 September 2015 09:21
> *To:* Matthew Pickering
> *Cc:* GHC developers
> *Subject:* Re: Shared data type for extension flags
>
>
>
> That sounds like a good approach. Are there other things that would go
> nicely
> in a shared package like this, in addition to the extension data type?
>
>
>
> On Wed, Sep 2, 2015 at 1:00 AM, Matthew Pickering <
> matthewtpicker...@gmail.com> wrote:
>
> Surely the easiest way here (including for other tooling - ie
> haskell-src-exts) is to create a package which just provides this
> enumeration. GHC, cabal, th, haskell-src-exts and so on then all
> depend on this package rather than creating their own enumeration.
>
>
> On Wed, Sep 2, 2015 at 9:47 AM, Michael Smith  wrote:
> > #10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the
> > capababilty
> > to Template Haskell to detect which language extensions enabled.
> > Unfortunately,
> > since template-haskell can't depend on ghc (as ghc depends on
> > template-haskell),
> > it can't simply re-export the ExtensionFlag type from DynFlags to the
> user.
> >
> > There is a second data type encoding the list of possible language
> > extensions in
> > the Cabal package, in Language.Haskell.Extension [3]. But
> template-haskell
> > doesn't already depend on Cabal, and doing so seems like it would cause
> > difficulties, as the two packages can be upgraded separately.
> >
> > So adding this new feature to Template Haskell requires introducing a
> > *third*
> > data type for language extensions. It also requires enumerating this full
> > list
> > in two more places, to convert back and forth between the TH Extension
> data
> > type
> > and GHC's internal ExtensionFlag data type.
> >
> > Is there another way here? Can there be one single shared data type for
> this
> > somehow?
> >
> > [1] https://ghc.haskell.org/trac/ghc/ticket/10820
> > [2] https://phabricator.haskell.org/D1200
> > [3]
> >
> https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Extension.html
> >
>
> > ___
> > 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: more releases

[Ben Gamari]

Richard Eisenberg  writes:

> I think some of my idea was misunderstood here: my goal was to have
> quick releases only from the stable branch. The goal would not be to
> release the new and shiny, but instead to get bugfixes out to users
> quicker. The new and shiny (master) would remain as it is now. In
> other words: more users would be affected by this change than just the
> vanguard.
>
I see. This is something we could certainly do.

It would require, however, that we be more pro-active about
continuing to merge things to the stable branch after the release.
Currently the stable branch is essentially in the same state that it was
in for the 7.10.2 release. I've left it this way as it takes time and
care to cherry-pick patches to stable. Thusfar my poilcy has been to
perform this work lazily until it's clear that we will do
another stable release as otherwise the effort may well be wasted.

So, even if the steps of building, testing, and uploading the release
are streamlined more frequent releases are still far from free. Whether
it's a worthwhile cost I don't know.

This is a difficult question to answer without knowing more about how
typical users actually acquire GHC. For instance, this effort would
have minimal impact on users who get their compiler through their
distribution's package manager. On the other hand, if most users
download GHC bindists directly from the GHC download page, then perhaps
this would be effort well-spent.

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: accept pull requests on GitHub

[Greg Weber]

I like Niklas's suggestion of a middle-ground approach. There are benefits
to using phabricator (and arc), but there should be a lowered-bar approach
where people can start contributing through github (even though they may be
forced to do the code review on phabricator).

On Tue, Sep 1, 2015 at 1:42 PM, Niklas Hambüchen  wrote:

> Hi,
>
> I would recommend against moving code reviews to Github.
> I like it and use it all the time for my own projects, but for a large
> project like GHC, its code reviews are too basic (comments get lost in
> multi-round reviews), and its customisation an process enforcement is
> too weak; but that has all been mentioned already on the
> https://ghc.haskell.org/trac/ghc/wiki/WhyNotGitHub page you linked.
>
> I do however recommend accepting pull requests via Github.
>
> This is already the case for simple changes: In the past I asked Austin
> "can you pull this from my branch on Github called XXX", and it went in
> without problems and without me having to use arc locally.
>
> But this process could be more automated:
>
> For Ganeti (cluster manager made by Google, written largely in Haskell)
> I built a tool (https://github.com/google/pull-request-mailer) that
> listens for pull requests and sends them to the mailing list (Ganeti's
> preferred way of accepting patches and doing reviews). We built it
> because some people (me included) liked the Github workflow (push
> branch, click button) more than `git format-patch`+`git send-email`. You
> can see an example at https://github.com/ganeti/ganeti/pull/22.
> The tool then replies on Github that discussion of the change please be
> held on the mailing list. That has worked so far.
> It can also handle force-pushes when a PR gets updated based on
> feedback. Writing it and setting it up only took a few days.
>
> I think it wouldn't be too difficult to do the same for GHC: A small
> tool that imports Github PRs into Phabricator.
>
> I don't like the arc user experience. It's modeled in the same way as
> ReviewBoard, and just pushing a branch is easier in my opinion.
>
> However, Phabricator is quite good as a review tool. Its inability to
> review multiple commits is nasty, but I guess that'll be fixed at some
> point. If not, such an import tool I suggest could to the squashing for
> you.
>
> Unfortunately there is currently no open source review tool that can
> handle reviewing entire branches AND multiple revisions of such
> branches. It's possible to build them though, some companies have
> internal review tools that do it and they work extremely well.
>
> I believe that a simple automated import setup could address many of the
> points in https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator.
>
> Niklas
>
> On 01/09/15 20:34, Thomas Miedema wrote:
> > Hello all,
> >
> > my arguments against Phabricator are here:
> > https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator.
> >
> > Some quotes from #ghc to pique your curiosity (there are some 50 more):
> >  * "is arc broken today?"
> >  * "arc is a frickin' mystery."
> >  * "i have a theory that i've managed to create a revision that phab
> > can't handle."
> >  * "Diffs just seem to be too expensive to create ... I can't blame
> > contributors for not wanting to do this for every atomic change"
> >  * "but seriously, we can't require this for contributing to GHC... the
> > entry barrier is already high enough"
> >
> > GitHub has side-by-side diffs
> >  nowadays, and
> > Travis-CI can run `./validate --fast` comfortably
> > .
> >
> > *Proposal: accept pull requests from contributors on
> > https://github.com/ghc/ghc.*
> >
> > Details:
> >  * use Travis-CI to validate pull requests.
> >  * keep using the Trac issue tracker (contributors are encouraged to put
> > a link to their pull-request in the 'Differential Revisions' field).
> >  * keep using the Trac wiki.
> >  * in discussions on GitHub, use https://ghc.haskell.org/ticket/1234 to
> > refer to Trac ticket 1234. The shortcut #1234 only works on Trac itself.
> >  * keep pushing to git.haskell.org , where the
> > existing Git receive hooks can do their job keeping tabs, trailing
> > whitespace and dangling submodule references out, notify Trac and send
> > emails. Committers close pull-requests manually, just like they do Trac
> > tickets.
> >  * keep running Phabricator for as long as necessary.
> >  * mention that pull requests are accepted on
> > https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs.
> >
> > My expectation is that the majority of patches will start coming in via
> > pull requests, the number of contributions will go up, commits will be
> > smaller, and there will be more of them per pull request (contributors
> > will be able to put style changes and refactorings into separate
> > commits, without jumping through a bunch of hoops).
> >
> > Reviewers will get many more emails.

Re: more releases

[Richard Eisenberg]

I think some of my idea was misunderstood here: my goal was to have quick 
releases only from the stable branch. The goal would not be to release the new 
and shiny, but instead to get bugfixes out to users quicker. The new and shiny 
(master) would remain as it is now. In other words: more users would be 
affected by this change than just the vanguard.

Richard

On Sep 2, 2015, at 3:43 AM, Ben Gamari  wrote:

> Richard Eisenberg  writes:
> 
>> On Sep 1, 2015, at 12:01 AM, Herbert Valerio Riedel  
>> wrote:
>> 
>>> I'd say mostly organisational overhead which can't be fully automated
>>> (afaik, Ben has already automated large parts but not everything can be):
>>> 
>>> - Coordinating with people creating and testing the bindists
>> 
>> This was the sort of thing I thought could be automated. I'm picturing
>> a system where Austin/Ben hits a button and everything whirs to life,
>> creating, testing, and posting bindists, with no people involved.
>> 
> I can nearly do this for Linux with my existing tools. I can do 32- and
> 64-bit builds for both RedHat and Debian all on a single
> Debian 8 machine with the tools I developed during the course of the
> 7.10.2 release [1].
> 
> Windows is unfortunately still a challenge. I did the 7.10.2 builds on
> an EC2 instance and the experience wasn't terribly fun. I would love for
> this to be further automated but I've not done this yet.
> 
>>> - Writing releases notes & announcment
>> 
>> Release notes should, theoretically, be updated with the patches.
>> Announcement can be automated.
>> 
> If I'm doing my job well the release notes shouldn't be a problem. I've
> been trying to be meticulous about ensuring that all new features come
> with acceptable release notes.
> 
>>> - If bundled core-libraries are affected, coordination overhead with package
>>>  maintainers (unless GHC HQ owned), verifying version bumps (API diff!) and
>>>  changelogs have been updated accordingly, uploading to Hackage
>> 
>> Any library version change would require a more proper release. Do
>> these libraries tend to change during a major release cycle?
>> 
> The core libraries are perhaps the trickiest part of this. Currently the
> process goes something like this,
> 
>  1. We branch off a stable GHC release
>  2. Development continues on `master`, eventually a breaking change is
> merged to one of the libraries
>  3. Eventually someone notices and bumps the library's version
>  4. More breaking changes are merged to the library
>  5. We branch off for another stable release, right before the release
> we manually push the libraries to Hackage
>  6. Repeat from (2)
> 
> There can potentially be a lot of interface churn between steps 3 and 5.
> If we did releases in this period we would need to be much more careful
> about library versioning. I suspect this may end up being quite a bit of
> work to do properly.
> 
> Technically we could punt on this problem and just do the same sort of
> stable/unstable versioning for the libraries that we already do with GHC
> itself. This would mean, however, that we couldn't upload the libraries
> to Hackage.
> 
>>> - Uploading and signing packagees to download.haskell.org, and verifying
>>>  the downloads 
>> 
>> This isn't automated?
>> 
> It is now (see [2]). This shouldn't be a problem.
> 
>>> Austin & Ben probably have more to add to this list
>>> 
>> I'm sure they do.
>> 
>> Again, I'd be fine if the answer from the community is "it's just not
>> what we need". But I wanted to see if there were
>> technical/practical/social reasons why this was or wasn't a good idea.
>> If we do think it's a good idea absent those reasons, then we can work
>> on addressing those concerns.
>> 
> Technically I think there are no reasons why this isn't feasible with
> some investment. Exactly how much investment depends upon what
> exactly we want to achieve,
> 
> * How often do we make these releases?
> * Which platforms do we support?
> * How carefully do we version included libraries?
> 
> If we focus solely on Linux and punt on the library versioning issue I
> would say this wouldn't even difficult. I could easily setup my build
> machine to do a nightly bindist and push it to a server somewhere.
> Austin has also mentioned that Harbormaster builds could potentially
> produce bindists.
> 
> The question is whether users want more rapid releases. Those working on
> GHC will use their own builds. Most users want something reasonably
> stable (in both the interface sense and the reliability sense) and
> therefore I suspect would stick with the releases. This leaves a
> relatively small number of potential users; namely those who want to
> play around with unreleased features yet aren't willing to do their own
> builds.
> 
> Cheers,
> 
> - Ben
> 
> 
> [1] https://github.com/bgamari/ghc-utils
> [2] https://github.com/bgamari/ghc-utils/blob/master/rel-eng/upload.sh

___
ghc-devs mailing list
ghc-devs@haskell.org
http:/

Re: [Haskell] ETA on 7.10.3?

[Andrew Farmer]

Sorry, I dropped the ball on creating a ticket. I just did so:

https://ghc.haskell.org/trac/ghc/ticket/10829

(As an aside, the original ticket, #10528, had a milestone set as
7.10.3, so I just assumed a 7.10.3 was planned and coming soon.)

On Wed, Sep 2, 2015 at 7:43 AM, Simon Peyton Jones
 wrote:
> Ah, well  https://github.com/ku-fpg/hermit/issues/144#issuecomment-128762767
>
> links in turn to https://github.com/ku-fpg/hermit/issues/141, which is a
> long thread I can’t follow.
>
>
>
> Ryan, Andy: if 7.10.2 is unusable for you, for some reason, please make a
> ticket to explain why, and ask for 7.10.3.
>
>
> Simon
>
>
>
> From: Haskell [mailto:haskell-boun...@haskell.org] On Behalf Of David Banas
> Sent: 02 September 2015 13:19
> To: Ben Gamari
> Cc: hask...@haskell.org
> Subject: Re: [Haskell] ETA on 7.10.3?
>
>
>
> Hi Ben,
>
>
>
> Thanks for your reply.
>
>
>
> My problem is the project I’m currently working on is dependent upon HERMIT,
> which doesn’t play well with 7.10.2, as per:
>
>
>
> https://github.com/ku-fpg/hermit/issues/144#issuecomment-128762767
>
>
>
> (The nature of that comment caused me to think that 7.10.3 was in play.)
>
>
>
> Thanks,
>
> -db
>
>
>
> On Sep 2, 2015, at 12:05 AM, Ben Gamari  wrote:
>
>
>
> David Banas  writes:
>
>
> Hi,
>
> Does anyone have an ETA for ghc v7.10.3?
> (I'm trying to decide between waiting and backing up to 7.8.2, for a
> particular project.)
>
> Currently there are no plans to do a 7.10.3 release. 7.10.2 does has a
> few issues, but none of them are critical regressions but none of them
> appear critical enough to burn maintenance time on.
>
> Of course, we are willing to reevaluate in the event that new issues
> arise. What problems with 7.10.2 are you struggling with?
>
> Cheers,
>
> - Ben
>
>
>
>
> ___
> 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: [Haskell] ETA on 7.10.3?

[Simon Peyton Jones]

Ah, well  https://github.com/ku-fpg/hermit/issues/144#issuecomment-128762767
links in turn to https://github.com/ku-fpg/hermit/issues/141, which is a long 
thread I can't follow.

Ryan, Andy: if 7.10.2 is unusable for you, for some reason, please make a 
ticket to explain why, and ask for 7.10.3.

Simon

From: Haskell [mailto:haskell-boun...@haskell.org] On Behalf Of David Banas
Sent: 02 September 2015 13:19
To: Ben Gamari
Cc: hask...@haskell.org
Subject: Re: [Haskell] ETA on 7.10.3?

Hi Ben,

Thanks for your reply.

My problem is the project I'm currently working on is dependent upon HERMIT, 
which doesn't play well with 7.10.2, as per:

https://github.com/ku-fpg/hermit/issues/144#issuecomment-128762767

(The nature of that comment caused me to think that 7.10.3 was in play.)

Thanks,
-db

On Sep 2, 2015, at 12:05 AM, Ben Gamari 
mailto:b...@smart-cactus.org>> wrote:


David Banas mailto:capn.fre...@gmail.com>> writes:


Hi,

Does anyone have an ETA for ghc v7.10.3?
(I'm trying to decide between waiting and backing up to 7.8.2, for a
particular project.)
Currently there are no plans to do a 7.10.3 release. 7.10.2 does has a
few issues, but none of them are critical regressions but none of them
appear critical enough to burn maintenance time on.

Of course, we are willing to reevaluate in the event that new issues
arise. What problems with 7.10.2 are you struggling with?

Cheers,

- Ben

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

RE: Shared data type for extension flags

[Simon Peyton Jones]

we already have such a shared library, I think: bin-package-db.  would that do?

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Michael Smith
Sent: 02 September 2015 09:21
To: Matthew Pickering
Cc: GHC developers
Subject: Re: Shared data type for extension flags

That sounds like a good approach. Are there other things that would go nicely
in a shared package like this, in addition to the extension data type?

On Wed, Sep 2, 2015 at 1:00 AM, Matthew Pickering 
mailto:matthewtpicker...@gmail.com>> wrote:
Surely the easiest way here (including for other tooling - ie
haskell-src-exts) is to create a package which just provides this
enumeration. GHC, cabal, th, haskell-src-exts and so on then all
depend on this package rather than creating their own enumeration.

On Wed, Sep 2, 2015 at 9:47 AM, Michael Smith 
mailto:mich...@diglumi.com>> wrote:
> #10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the
> capababilty
> to Template Haskell to detect which language extensions enabled.
> Unfortunately,
> since template-haskell can't depend on ghc (as ghc depends on
> template-haskell),
> it can't simply re-export the ExtensionFlag type from DynFlags to the user.
>
> There is a second data type encoding the list of possible language
> extensions in
> the Cabal package, in Language.Haskell.Extension [3]. But template-haskell
> doesn't already depend on Cabal, and doing so seems like it would cause
> difficulties, as the two packages can be upgraded separately.
>
> So adding this new feature to Template Haskell requires introducing a
> *third*
> data type for language extensions. It also requires enumerating this full
> list
> in two more places, to convert back and forth between the TH Extension data
> type
> and GHC's internal ExtensionFlag data type.
>
> Is there another way here? Can there be one single shared data type for this
> somehow?
>
> [1] https://ghc.haskell.org/trac/ghc/ticket/10820
> [2] https://phabricator.haskell.org/D1200
> [3]
> https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Extension.html
>
> ___
> 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: more releases

[Herbert Valerio Riedel]

On 2015-09-02 at 12:43:57 +0200, Ben Gamari wrote:

[...]

> The question is whether users want more rapid releases. Those working on
> GHC will use their own builds. Most users want something reasonably
> stable (in both the interface sense and the reliability sense) and
> therefore I suspect would stick with the releases. This leaves a
> relatively small number of potential users; namely those who want to
> play around with unreleased features yet aren't willing to do their own
> builds.

Btw, for those who are willing to use Ubuntu there's already GHC HEAD
builds available in my PPA, and I can easily keep creating GHC 7.10.3
snapshots in the same style like I usually do shortly before a stable
point-release.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: more releases

[Ben Gamari]

Richard Eisenberg  writes:

> On Sep 1, 2015, at 12:01 AM, Herbert Valerio Riedel  
> wrote:
>
>> I'd say mostly organisational overhead which can't be fully automated
>> (afaik, Ben has already automated large parts but not everything can be):
>> 
>> - Coordinating with people creating and testing the bindists
>
> This was the sort of thing I thought could be automated. I'm picturing
> a system where Austin/Ben hits a button and everything whirs to life,
> creating, testing, and posting bindists, with no people involved.
>
I can nearly do this for Linux with my existing tools. I can do 32- and
64-bit builds for both RedHat and Debian all on a single
Debian 8 machine with the tools I developed during the course of the
7.10.2 release [1].

Windows is unfortunately still a challenge. I did the 7.10.2 builds on
an EC2 instance and the experience wasn't terribly fun. I would love for
this to be further automated but I've not done this yet.

>> - Writing releases notes & announcment
>
> Release notes should, theoretically, be updated with the patches.
> Announcement can be automated.
>
If I'm doing my job well the release notes shouldn't be a problem. I've
been trying to be meticulous about ensuring that all new features come
with acceptable release notes.

>> - If bundled core-libraries are affected, coordination overhead with package
>>   maintainers (unless GHC HQ owned), verifying version bumps (API diff!) and
>>   changelogs have been updated accordingly, uploading to Hackage
>
> Any library version change would require a more proper release. Do
> these libraries tend to change during a major release cycle?
> 
The core libraries are perhaps the trickiest part of this. Currently the
process goes something like this,

  1. We branch off a stable GHC release
  2. Development continues on `master`, eventually a breaking change is
 merged to one of the libraries
  3. Eventually someone notices and bumps the library's version
  4. More breaking changes are merged to the library
  5. We branch off for another stable release, right before the release
 we manually push the libraries to Hackage
  6. Repeat from (2)

There can potentially be a lot of interface churn between steps 3 and 5.
If we did releases in this period we would need to be much more careful
about library versioning. I suspect this may end up being quite a bit of
work to do properly.

Technically we could punt on this problem and just do the same sort of
stable/unstable versioning for the libraries that we already do with GHC
itself. This would mean, however, that we couldn't upload the libraries
to Hackage.

>> - Uploading and signing packagees to download.haskell.org, and verifying
>>   the downloads 
>
> This isn't automated?
>
It is now (see [2]). This shouldn't be a problem.

>> Austin & Ben probably have more to add to this list
>> 
> I'm sure they do.
>
> Again, I'd be fine if the answer from the community is "it's just not
> what we need". But I wanted to see if there were
> technical/practical/social reasons why this was or wasn't a good idea.
> If we do think it's a good idea absent those reasons, then we can work
> on addressing those concerns.
>
Technically I think there are no reasons why this isn't feasible with
some investment. Exactly how much investment depends upon what
exactly we want to achieve,

 * How often do we make these releases?
 * Which platforms do we support?
 * How carefully do we version included libraries?

If we focus solely on Linux and punt on the library versioning issue I
would say this wouldn't even difficult. I could easily setup my build
machine to do a nightly bindist and push it to a server somewhere.
Austin has also mentioned that Harbormaster builds could potentially
produce bindists.

The question is whether users want more rapid releases. Those working on
GHC will use their own builds. Most users want something reasonably
stable (in both the interface sense and the reliability sense) and
therefore I suspect would stick with the releases. This leaves a
relatively small number of potential users; namely those who want to
play around with unreleased features yet aren't willing to do their own
builds.

Cheers,

- Ben


[1] https://github.com/bgamari/ghc-utils
[2] https://github.com/bgamari/ghc-utils/blob/master/rel-eng/upload.sh


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

Re: Shared data type for extension flags

[Michael Smith]

That sounds like a good approach. Are there other things that would go
nicely
in a shared package like this, in addition to the extension data type?

On Wed, Sep 2, 2015 at 1:00 AM, Matthew Pickering <
matthewtpicker...@gmail.com> wrote:

> Surely the easiest way here (including for other tooling - ie
> haskell-src-exts) is to create a package which just provides this
> enumeration. GHC, cabal, th, haskell-src-exts and so on then all
> depend on this package rather than creating their own enumeration.
>
> On Wed, Sep 2, 2015 at 9:47 AM, Michael Smith  wrote:
> > #10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the
> > capababilty
> > to Template Haskell to detect which language extensions enabled.
> > Unfortunately,
> > since template-haskell can't depend on ghc (as ghc depends on
> > template-haskell),
> > it can't simply re-export the ExtensionFlag type from DynFlags to the
> user.
> >
> > There is a second data type encoding the list of possible language
> > extensions in
> > the Cabal package, in Language.Haskell.Extension [3]. But
> template-haskell
> > doesn't already depend on Cabal, and doing so seems like it would cause
> > difficulties, as the two packages can be upgraded separately.
> >
> > So adding this new feature to Template Haskell requires introducing a
> > *third*
> > data type for language extensions. It also requires enumerating this full
> > list
> > in two more places, to convert back and forth between the TH Extension
> data
> > type
> > and GHC's internal ExtensionFlag data type.
> >
> > Is there another way here? Can there be one single shared data type for
> this
> > somehow?
> >
> > [1] https://ghc.haskell.org/trac/ghc/ticket/10820
> > [2] https://phabricator.haskell.org/D1200
> > [3]
> >
> https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Extension.html
> >
> > ___
> > 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: Shared data type for extension flags

[Matthew Pickering]

Surely the easiest way here (including for other tooling - ie
haskell-src-exts) is to create a package which just provides this
enumeration. GHC, cabal, th, haskell-src-exts and so on then all
depend on this package rather than creating their own enumeration.

On Wed, Sep 2, 2015 at 9:47 AM, Michael Smith  wrote:
> #10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the
> capababilty
> to Template Haskell to detect which language extensions enabled.
> Unfortunately,
> since template-haskell can't depend on ghc (as ghc depends on
> template-haskell),
> it can't simply re-export the ExtensionFlag type from DynFlags to the user.
>
> There is a second data type encoding the list of possible language
> extensions in
> the Cabal package, in Language.Haskell.Extension [3]. But template-haskell
> doesn't already depend on Cabal, and doing so seems like it would cause
> difficulties, as the two packages can be upgraded separately.
>
> So adding this new feature to Template Haskell requires introducing a
> *third*
> data type for language extensions. It also requires enumerating this full
> list
> in two more places, to convert back and forth between the TH Extension data
> type
> and GHC's internal ExtensionFlag data type.
>
> Is there another way here? Can there be one single shared data type for this
> somehow?
>
> [1] https://ghc.haskell.org/trac/ghc/ticket/10820
> [2] https://phabricator.haskell.org/D1200
> [3]
> https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Extension.html
>
> ___
> 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

Shared data type for extension flags

[Michael Smith]

#10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the
capababilty
to Template Haskell to detect which language extensions enabled.
Unfortunately,
since template-haskell can't depend on ghc (as ghc depends on
template-haskell),
it can't simply re-export the ExtensionFlag type from DynFlags to the user.

There is a second data type encoding the list of possible language
extensions in
the Cabal package, in Language.Haskell.Extension [3]. But template-haskell
doesn't already depend on Cabal, and doing so seems like it would cause
difficulties, as the two packages can be upgraded separately.

So adding this new feature to Template Haskell requires introducing a
*third*
data type for language extensions. It also requires enumerating this full
list
in two more places, to convert back and forth between the TH Extension data
type
and GHC's internal ExtensionFlag data type.

Is there another way here? Can there be one single shared data type for this
somehow?

[1] https://ghc.haskell.org/trac/ghc/ticket/10820
[2] https://phabricator.haskell.org/D1200
[3]
https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Extension.html
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs