- ghc-devs - Haskell.org

Getting rid of -XImpredicativeTypes
by Simon Peyton Jones 03 Oct '16

03 Oct '16

Friends GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to support impredicative polymorphism. But it is vestigial.... if it works, it's really a fluke. We don't really have a systematic story here at all. I propose, therefore, to remove it entirely. That is, if you use -XImpredicativeTypes, you'll get a warning that it does nothing (ie. complete no-op) and you should remove it. Before I pull the trigger, does anyone think they are using it in a mission-critical way? Now that we have Visible Type Application there is a workaround: if you want to call a polymorphic function at a polymorphic type, you can explicitly apply it to that type. For example: {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-} module Vta where f x = id @(forall a. a->a) id @Int x You can also leave out the @Int part of course. Currently we have to use -XImpredicativeTypes to allow the @(forall a. a->a). Is that sensible? Or should we allow it regardless? I rather think the latter... if you have Visible Type Application (i.e. -XTypeApplications) then applying to a polytype is nothing special. So I propose to lift that restriction. I should go through the GHC Proposals Process for this, but I'm on a plane, so I'm going to at least start with an email. Simon

9 15

Re: How, precisely, can we improve?
by Moritz Angermann 02 Oct '16

02 Oct '16

Richard, thank you for trying to give this some technical basis. As someone who as contributed some tiny bugfixes to ghc, I found the process a bit cumbersome, yet manageable[1]. I’d however like to propose some concrete changes, and please excuse if these have been discussed and found to not be actionable. What I’d really like to see improved is the “multiple (web)services, multiple accounts” issue solved. As it is right now I need to have a github account (ghc-proposals, soon tiny PR against ghc), a trac account (for the wiki and issue tracker; which never seems to remember me), a phabricator account[2], likely a stack overflow account for questions and answers. On top of that I also need to be on a large set of mailing lists if I want to not miss anything, and an irc client and twitter client to tap into the most recent discussions. And there’s another wiki on haskell.org for which I would need to sign up and get an approved account. I’d like to see the following: 1. Unify the issue tracker and code review into phabricator. Hence *if* I want to contribute to the ghc codebase, I essentially only need a phabricator account[3]. And a simple one page website on haskell.org that runs me through the “Contributing to GHC” as in: > GHC Development is facilitated through phabricator. > > Please go to https://phabricator.haskell.org[4] and > create an account. > > If you want to report a bug, please file a bugreport through > the “Maniphest” module, you can find on the left. > > If you are looking for something to contribute, and browse the > Open Tasks at https://phabricator.haskell.org/maniphest/query/open/[5] > > Clone the GHC tree and build it > [ clone and build instructions here; note about stage2 pinning to reduce compile times and other > build system features ] > > Hack to your hearts content on GHC (you might get some quick responses > regarding ghc’s internals at irc://irc.freenode.net/ghc, as well as in > the ghc commentary at …[6], or the ghc-dev mailing list for which you > can sign up at ...) > > Validate your build [ plus instructions how to do so, and how to run > performance measurements on the changed ghc; if one is interested in > that as well ] > > Upload your patch to GHC using the arc command line tool. You will have > to set up your token during the first use, just follow the instructions. > > To upload your patch, commit your local changes; and run > $ arc diff origin/master > > arc will run a few linters against your diff, and provide you with a form > to fill in all the details regarding your patch. This form is usually > prepopulated with the commit messages from your local commits. > > During the review process you might have to update your diff. To do so > you can rebase your changes against the most recent master and/or add > additional commits to it; once you are done updating your patch, run > $ arc diff --update > > Once your diff has been accepted, someone with commit rights with “land” your > diff into the official ghc tree. And have this prominently liked from https://www.haskell.org/ under “Contributing” 2. Move the Wiki someplace else. I don’t know if the wiki in phabricator is any good, I’ve never used it. However, finding something in the ghc wiki has been more hit and miss for me than anything else. The built in search almost never reveals what I’m looking for, and resorting to a search engine only sometimes helps me find what I’m looking for. (This might totally be my fault). 3. Reduce the number of Mailing lists. I’m supposedly not on the haskell ml; so I missed https://mail.haskell.org/pipermail/haskell/2016-September/024995.html, and only saw it due to https://twitter.com/ezyang/status/780134457101516800. Are our MLs really that high volume that we need so many? 4. I like the idea of trivial pull requests to be accepted on GH as well. And I don’t see it as a big hurdle to ask someone to please be so kind and submit the patch through phabricator if it’s more involved with a link to https://www.haskell.org/contributing (see above). In conclusion I’d like to propose to reduce the fragmentation of tooling, and accept the status quo of what open source development seems looks like to many (github for code, stackoverflow questions (and documentation soon?)) as much as we can. Cheers, Moritz — [1]: I didn’t understand phabriactor and arc in the beginning, however today I appreciate the process phabricator and arc offer a lot! (Over PRs) [2]: for which you can actually use your bitbucket, github, twitter, … account. [3]: I will also need some access to the staging area, if I want to use that feature. [4]: Can we have http://phabricator.haskell.org redirect to https://phabricator.haskell.org? Instead of having both? [5]: I guess one could create some Trivial, Easy, Medium and Hard queries. [6]: This is currently scattered across the trac wiki. > On Sep 26, 2016, at 9:27 AM, Richard Eisenberg <rae(a)cs.brynmawr.edu> wrote: > > Like many of you, I'm sure, I'm saddened by the occasional tone of the recent exchange about contributions to GHC. > > I'd like to move the conversation forward -- and I'd like to do so on a technical basis. > > So, I ask: > How, precisely, can we improve? > > I think it would be best to have answers to this question start their own thread, as I expect several good answers to this question. > > As I ask this, I am not making the assumption that we cannot, nor is this meant to be rhetorical. I am asking a question in search of precise, technical answers. > > "Be more like Rust" is not an answer to this question, as it is imprecise. (I'm not at all maligning the overall goal of emulating a successful process. It's just that "be more like Rust" is not actionable.) > > "Accept PRs on GitHub" *is* an answer to this question, but one we have revisited several times in recent memory. (I believe https://mail.haskell.org/pipermail/ghc-devs/2015-September/009744.html is the most recent.) Perhaps we can revisit this yet again, but it would be great if new technical content can be injected into the debate. I hope the rejection of the proposal linked there is not considered "dismissive", as the proposal generated vigorous debate -- the opposite of dismissiveness. (For what it's worth, I'm weakly in favor of accepting PRs on GitHub. However, I have no experience setting up or maintaining infrastructure for an open source project and have happily deferred to those who have such experience and who have come out against this idea.) > > "Have process (X) for accepting new language features" *is* an answer to my question. This is in flight and I hope addresses the concern in the community. It seems to me that this step addresses the grievances described in "The Process" part of http://www.arcadianvisions.com/blog/2016/ghc-contributing.html > > "Have a formal mentorship system" *is* another answer to my question, and one I think we can readily adopt. Can you (for all values of "you") suggest a concrete model with a link? It seems to me that folks who ask for help get the help they need. But this surely requires the courage and wherewithal to ask for the help. Perhaps there is a better way to advertise our availability and desire to mentor. I, personally, have onboarded (or attempted to) several contributors and enjoy doing so. Though my ability to mentor wanes when I have gotten busy, I have always prioritized helping out the newest contributors, letting other, more confident actors' emails slip if necessary. If I have erred, I am sorry. > > "Don't be dismissive" is not an answer to my question, as it is both imprecise and not technical. The most recent thread indeed had posts that seemed quite dismissive, but these posts emanated from people with a variety of viewpoints. It was hardly GHC HQ (whatever that means). What, precisely, has been dismissed? It looks to me that we (regular GHC contributors) take the community's concerns seriously. Fixes may be slow in coming, but that's not dismissiveness. Of course I'm biased here, but I am truly and earnestly asking for clarification. > > Emboldened by the technical, respectful discussion recently on the merits (and usage patterns) of stack (starting at https://mail.haskell.org/pipermail/haskell-cafe/2016-September/124847.html) I look forward to a similarly technical, respectful discussion on our contribution process. > > Thanks for all that you (for all values of "you") do to help grow our community and make it stronger. > > Richard > > -=-=-=-=-=-=-=-=-=-=- > Richard A. Eisenberg > Asst. Prof. of Computer Science > Bryn Mawr College > Bryn Mawr, PA, USA > cs.brynmawr.edu/~rae > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

16 39

[GHC Proposal] Allow use of TypeApplications in SPECIALISE pragmas
by Ben Gamari 01 Oct '16

01 Oct '16

Hello everyone, I just opened Pull Request #15 [1] against the ghc-proposals repository, describing a propsed extension to the syntax of the SPECIALISE pragma, allowing significantly more concise usage. Please give it a read through and leave your comments. Thanks! Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/15

1 0

[GHC Proposal] Type-indexed Typeable
by Ben Gamari 01 Oct '16

01 Oct '16

Hello everyone, I just opened Pull Request #16 [1] against the ghc-proposals repository, describing the new Type-indexed Typeable machinery that we would like to introduce with GHC 8.2. Please give it a read through and leave your comments. Thanks! Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/16

1 0

RE: [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail
by Simon Peyton Jones 30 Sep '16

30 Sep '16

rn003 is failing apparently (see below) But it’s fine on my machine. I don’t know how to see the actual error message. Any ideas? Simon From: noreply(a)phabricator.haskell.org [mailto:noreply@phabricator.haskell.org] Sent: 30 September 2016 17:31 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail Harbormaster failed to build B11120: rGHC3f27237b0e6d: Make tcrun042 fail! BRANCHES master USERS simonpj (Author) O7 (Auditor) COMMIT https://phabricator.haskell.org/rGHC3f27237b0e6d EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj, Harbormaster

3 3

RE: [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail
by Simon Peyton Jones 30 Sep '16

30 Sep '16

Thanks Chris, that’s helpful. I got to your final link, but it didn’t show me what rn003 did. There seem to be two logs for some reason. I tried clicking “Unlimited” lines, but I still didn’t see a clear failure from rn003. Does it fail for anyone else? From: Christopher Allen [mailto:cma@bitemyapp.com] Sent: 30 September 2016 17:41 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail For some contrast, at work if I get notification that a build failed, if I click the Red X in the Github PR I go straight to the build and its output. (Screenshot attached of where it takes me) On Fri, Sep 30, 2016 at 11:39 AM, Christopher Allen <cma(a)bitemyapp.com<mailto:cma@bitemyapp.com>> wrote: It's a bit tricky, you have to follow these steps: Click the commit link in the email: https://phabricator.haskell.org/rGHC3f27237b0e6d Click the build link on the commit page: B11120: rGHC3f27237b0e6d: Make tcrun042 fail<https://phabricator.haskell.org/B11120>! Click another build link on the build page: [GHC] Linux/amd64: Continuous Integration<https://phabricator.haskell.org/harbormaster/build/13355/> Then you're here: https://phabricator.haskell.org/harbormaster/build/13355/ which has the build output. On Fri, Sep 30, 2016 at 11:36 AM, Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> wrote: rn003 is failing apparently (see below) But it’s fine on my machine. I don’t know how to see the actual error message. Any ideas? Simon From: noreply(a)phabricator.haskell.org<mailto:noreply@phabricator.haskell.org> [mailto:noreply@phabricator.haskell.org<mailto:noreply@phabricator.haskell.org>] Sent: 30 September 2016 17:31 To: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Subject: [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail Harbormaster failed to build B11120: rGHC3f27237b0e6d: Make tcrun042 fail! BRANCHES master USERS simonpj (Author) O7 (Auditor) COMMIT https://phabricator.haskell.org/rGHC3f27237b0e6d EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj, Harbormaster _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel…> -- Chris Allen Currently working on http://haskellbook.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbook…> -- Chris Allen Currently working on http://haskellbook.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbook…>

2 1

git question
by Simon Peyton Jones 30 Sep '16

30 Sep '16

Friends I have a batch of several commits lined up on my local machine, validated, and ready to push to the master. But one seems to have accidentally got diff --git a/utils/haddock b/utils/haddock index 073d899..a3309e7 160000 --- a/utils/haddock +++ b/utils/haddock @@ -1 +1 @@ -Subproject commit 073d899a8f94ddec698f617a38d3420160a7fd0b +Subproject commit a3309e797c42dae9bccdeb17ce52fcababbaff8a I did not want to meddle with Haddock. Question: how can I remove this change from my commit? I know how to do git rebase –interactive, and I can aske to “edit” that commit… but what then? Thanks Simon

4 5

A few technical suggestions
by lonetiger＠gmail.com 30 Sep '16

30 Sep '16

Hi All, I wanted to give my own thoughts/suggestions for things we could do on the short/medium term To make things a bit better. As a whole I may be one of the few who likes the current setup so I Propose enhancing the current toolset. I find the mail patch to mailing list approach of GCC et al quite cumbersome to be honest. And the discussion quickly becomes hard to follow as it branches lot. My proposals (sorry for the brevity, I can expand if needed): * Link phab to github Phabricator seems to have build in OAuth support. As you'll likely need a github account anyway, why not also support github logins? This would reduce the barrier of needing multiple accounts that is often a complaint. Would it be possible to maybe also extract the user's public key from github automatically? That would reduce one of the barriers as well. https://secure.phabricator.com/book/phabricator/article/configuring_account… * Link Trac to github - used to login (OAuth support) - readonly issues (to begin with?). we already have a code mirror, why not mirror more content. - sync issues back between the two - gives us an ability to see which github users an issue affects since they can then reference it. - updates the users when an issue is fixed since it will be closed on GH. - Gives us an indication of the importance of the tickets As a whole, I find Trac MUCH better for ticket triaging than Github or Phab, both of which seem to be quite bare and simple in what they provide. I am not in favor of ditching it. Also we have and continue to accept patches just uploaded to Trac as a diff. We tend to ask people to upload it to phab for better reviews and so it's attributed to them when we commit. Some don't (and we then do it ourselves), most due. If they don't need another login then I suspect almost all would. There's a (seemingly) actively maintained project that does all the above, could we leverage it? https://github.com/trac-hacks/trac-github * There is a trac plugin to generate a new section on trac /doc which allows you to render and edit documentations checked into repo. Could this be used to allow easier editing of non generated documentation? It's currently based on SVN, but maybe a git one exists too? https://github.com/trac-hacks/tracdocs * Newcomers - Expose newcomers information more by creating a new landing page - Clean up build instructions. For windows, I have scripts to automate setup. Often heard complain is that it is hard, but never hear why it's hard. In any case, my setup script for a 100% unattended build env setup for Windows are here: https://github.com/Mistuke/GhcDevelChoco/releases These are entirely self contained environments that can be removed by a simple rm -rf /. You can have as many as you want on the same machine without them interfering with eachother or with whatever else you might have done to your GHC already installed. It's not 100% production ready but it works and does so well. * Updated Phab reviewers list to be more automated - Assign reviewers next to the static list (as is currently done) to maybe also include significant contributors to that file? The reason for this is that currently it's always the same people reviewing patches. Their time is spread thin. Particularly on less popular platforms it basically comes down to 4 people. * Update trac linters and pre-commit linters to be the same. - particularly reject summaries that would be rejected on commit. Often when I try landing patches (especially from others) I have to edit the summary. Maybe arc should reject the diff if a push would fail? Also I want to say I love the summary document you have to fill in. It ensures useful information is there later when I have to find out why a change was made. So whatever we do, don't remove this. * Phab plugin to on signup ask for public key if none found. - It's recently been made a requirement to require a public key to push to phab. The error you get when you don't do this and try to push a patch is very very cryptic and unintuitive. Could we make a plugin that asks the user to upload a public key on trac if they haven't done so? Like a banner at the top? * Automate trac tickets - Particular on new tickets post a friendly reminder that if they want they can give it a hand in fixing it themselves. - Parse information added, in particular check if reproduction steps are there etc. - If stack is used, kindly ask if a repo without can be used. The amount of bug reports with stack is increasing and regardless of my own opinion on the tool, these reports are not very useful as is. - Maybe automatically CC people from a pool based on the information in the ticket? I tend to miss tickets because my filters are quite strict. Generally if the ticket doesn't mention my name, is directed at me or has "Windows" in the body somewhere it will skip my inbox. I review filtered tickets only once a week. - If a newcomer assigns a ticket to themselves, have trac automatically post links to useful pages: * how to setup build environment. * how to get help * assign a mentor? * after x amount of time with no progress, remind them again that help is available Kind Regards, Tamar

3 2

Re: Request for feedback: deriving strategies syntax
by Ryan Scott 28 Sep '16

28 Sep '16

Hello, everyone! Sorry for not being able to respond to some of the recent feedback. Well, it seems I'm at a bit of an impasse again. I originally changed "builtin" to "bespoke" because enough GHC devs voiced their displeasure (ranging from moderate to severe) with "builtin". I hoped that choosing "bespoke" would strike a happy medium where we could have a term that (1) reasonably describes its intended purpose, (2) wouldn't be highly misleading upon an initial glance, and (3) wouldn't be too off-putting to use as a reserved keyword. Unfortunately, I over-estimated how well "bespoke" meets criterion 3, since several people have _also_ voiced their displeasure with it! (Again, ranging from moderate to severe.) So we're back to square one, it seems. I don't want to push this patch without a general feeling of community consensus, but the patch is complete after all, with the exception of bikeshedding, so I'd like to try and come up with a colo(u)r that folks will be happy with so we can proceed and I can work on other things that need this feature. So, instead of "builtin" and "bespoke", I propose reconsidering an earlier suggestion of Elliot Cameron's: "standard". I had previously expressed reservations about "standard" before, since I felt it might be miscontrued as meaning "a Haskell standard" (e.g., the Haskell Report). But upon further thought, I have actually come to like the word "standard". Here's why: 1. It's simple. "Standard" is recognizable whether you speak American English, British English, or pretty much any other variant that I'm aware of. 2. It has precedent. A GHC error message already uses the phrase "standard derivable classes" to refer to Eq, Ord, Functor, etc. If we adopt "standard" as our keyword, then we could endow this phrase with a more precise meaning. 3. It reflects history. This deriving strategy (that I'm proposing to name "standard") was the very first deriving strategy that GHC supported (to my knowledge), so it makes sense to refer to this strategy as the "standard" one, since all other strategies were added later. 4. It's not too ambiguous. As opposed to say, "default" (which could be confused with -XDefaultSignatures, i.e., the anyclass strategy), I think that "standard" has a pretty obvious connotation in the context of deriving. There is the possibility of misinterpreting "standard" to refer to the Haskell Report, but that wouldn't be the worst misconception in the world to make, since several "standard derivable classes" are actually in the Haskell Report (whereas neither GeneralizedNewtypeDeriving nor DeriveAnyClass are). What does everyone think? Ryan S.

6 7

How, precisely, can we improve?
by Richard Eisenberg 28 Sep '16

28 Sep '16

Like many of you, I'm sure, I'm saddened by the occasional tone of the recent exchange about contributions to GHC. I'd like to move the conversation forward -- and I'd like to do so on a technical basis. So, I ask: How, precisely, can we improve? I think it would be best to have answers to this question start their own thread, as I expect several good answers to this question. As I ask this, I am not making the assumption that we cannot, nor is this meant to be rhetorical. I am asking a question in search of precise, technical answers. "Be more like Rust" is not an answer to this question, as it is imprecise. (I'm not at all maligning the overall goal of emulating a successful process. It's just that "be more like Rust" is not actionable.) "Accept PRs on GitHub" *is* an answer to this question, but one we have revisited several times in recent memory. (I believe https://mail.haskell.org/pipermail/ghc-devs/2015-September/009744.html is the most recent.) Perhaps we can revisit this yet again, but it would be great if new technical content can be injected into the debate. I hope the rejection of the proposal linked there is not considered "dismissive", as the proposal generated vigorous debate -- the opposite of dismissiveness. (For what it's worth, I'm weakly in favor of accepting PRs on GitHub. However, I have no experience setting up or maintaining infrastructure for an open source project and have happily deferred to those who have such experience and who have come out against this idea.) "Have process (X) for accepting new language features" *is* an answer to my question. This is in flight and I hope addresses the concern in the community. It seems to me that this step addresses the grievances described in "The Process" part of http://www.arcadianvisions.com/blog/2016/ghc-contributing.html "Have a formal mentorship system" *is* another answer to my question, and one I think we can readily adopt. Can you (for all values of "you") suggest a concrete model with a link? It seems to me that folks who ask for help get the help they need. But this surely requires the courage and wherewithal to ask for the help. Perhaps there is a better way to advertise our availability and desire to mentor. I, personally, have onboarded (or attempted to) several contributors and enjoy doing so. Though my ability to mentor wanes when I have gotten busy, I have always prioritized helping out the newest contributors, letting other, more confident actors' emails slip if necessary. If I have erred, I am sorry. "Don't be dismissive" is not an answer to my question, as it is both imprecise and not technical. The most recent thread indeed had posts that seemed quite dismissive, but these posts emanated from people with a variety of viewpoints. It was hardly GHC HQ (whatever that means). What, precisely, has been dismissed? It looks to me that we (regular GHC contributors) take the community's concerns seriously. Fixes may be slow in coming, but that's not dismissiveness. Of course I'm biased here, but I am truly and earnestly asking for clarification. Emboldened by the technical, respectful discussion recently on the merits (and usage patterns) of stack (starting at https://mail.haskell.org/pipermail/haskell-cafe/2016-September/124847.html) I look forward to a similarly technical, respectful discussion on our contribution process. Thanks for all that you (for all values of "you") do to help grow our community and make it stronger. Richard -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae <http://cs.brynmawr.edu/~rae>

2 1