July 2026 - ghc-devs - Haskell.org

Re: LLM policy for GHC
by Simon Jakobi 14 Jul '26

14 Jul '26

Hi Simon, here are my comments on the policy document: > In particular, you must not use AI-generated text in a direct conversation with a human reviewer. I think this is too restrictive. A contributor may easily reach the limits of their understanding during a code review, and I think it's ok to resort to using an LLM then. I think it's fair to require that they clearly mark the LLM-generated part of their response though. > P1: Write MRs that are easy to review I fully agree with this, and apologize that some of my MRs have not been easy to review! I do want to point out though that MRs marked as "Draft" should not be held to the same standards as a "ready" / non-draft MR. I frequently open draft MRs mainly to get the CI results. Sometimes I still get detailed reviews on these MRs, and then feel sorry that a reviewer wasted their time on this. > P2: Full responsibility > You must understand, and be able to explain, every line of code, and every sentence of documentation. Every line! I think that's a good goal, but even for MRs, maybe too strict a requirement. Where do you draw the line? Is the contributor expected to understand every (pre-existing) function they used? To what extent? Strictness and performance characteristics too? For bug reports, I think GHC should be more lenient, and instead require that LLM use is clearly signalled. > P3: Strong preference for human authorship > We strongly prefer human-written code I understand that it's "good exercise" to write code by hand. But I've always been pretty bad and extremely slow to write code. And now that recent models have become so good at producing code, I was relieved that I can now contribute without being so limited by my code-writing skills. I already realize that some core contributors have much disdain for LLM-generated code. If the GHC project decides to devalue contributions of LLM-generated code with this language, I think this will reduce my motivation to contribute. > Writing it yourself forces you to think about every line; and it imposes a cost on you if you write 1000 lines instead of 100. IMHO contributing to GHC is already quite onerous and "costly", especially for newcomers. Just think of the flaky CI system and recent GitLab performance. Instead of trying to impose additional costs on contributors, I think it would be better to try to reduce the cost of reviewing and maintenance! For example, I think GHC should try using LLMs for "first-line" code review. LLMs are already very capable at debugging. How about investing in fuzzing or better automated testing, so bugs are discovered before they make it into a release? > We strongly prefer human-written documentation. Documentation generated by recentish models like Claude Opus 4.8 has indeed been quite bad. Claude Fable 5 is already much better at this. I think the main incentive resulting from this policy is to include _less_ documentation in contributions. In a world where LLMs are very capable of making sense of large code bases, maybe that's not much of a drawback. --- Overall, I feel that much of the recent discussion about LLMs in GHC and Haskell has been driven by fear and anger. I think many Haskellers are very proud of their skill to produce high-quality code, and as LLMs get better and better at this, this skill is becoming "less special". Instead of trying to discourage contributions that involve LLMs, I think this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users. Sorry for the bad wording here and there. I did not use an LLM to write these comments, and it took me an embarrassingly long time. Cheers, Simon

1 0

LLM policy for GHC
by Simon Peyton Jones 14 Jul '26

14 Jul '26

Dear GHC developers There has been some debate on #27433 <https://gitlab.haskell.org/ghc/ghc/-/issues/27433> about the role of LLMs in the GHC project. Informed by that discussion, and by the policies adopted by other language communities, I have had a go at drafting - this proposed policy <https://docs.google.com/document/d/1XxP8NXnbgr6faxXBXKw75zgoxIg-SzGv-Cvixyi…> I would welcome constructive feedback on it. As the draft tries to say, there are widely varying views in the community, so no policy will please everyone. I hope that, even where we disagree, we can do so agreeably. Criticism (respectful of course <https://haskell.foundation/guidelines-for-respectful-communication/>!) is absolutely fine, but positive, concrete suggestions for alternative wording is even better. Thank you to those who have already given me some private feedback, which has made the draft much better. Simon

6 10

few minute gitlab downtime
by Magnus Viernickel 14 Jul '26

14 Jul '26

Dear GHC Devs, there will be a short gitlab downtime (few minutes) right now because I need to adjust a setting to fix an issue with the deployment. Best Magnus

1 0

More Gitlab things
by Magnus Viernickel 12 Jul '26

12 Jul '26

Hi all, A couple of heads ups: 1. the gitlab container may tell your it's booting some times again today because I'm upgrading its host. This should only take a couple of minutes at most 2. CI might be impaired since we have some issues with gitlab's docker registry 3. if you're missing some of your commits on the MR, it doesn't mean they're lost, it means they will appear later. We currently have a bunch of load on the background task queue and when we catch up your stuff will start appearing. Best Magnus

1 0

Gitlab upgrade finished!
by Magnus Viernickel 12 Jul '26

12 Jul '26

Dear GHC Devs, I'm happy to tell you that Ben and I successfully upgraded the postgres yesterday. Ben heroically pulled through with the gitlab upgrade all the way to the latest available until 7am my time! Huge thank you to the heroic work of Ben, taking the time and nerves to put up with this non-sense. It took at total of 14 hours until he was finished. Have fun with the new UI. Best Magnus

2 1

gitlab
by Magnus Viernickel 12 Jul '26

12 Jul '26

Dear GHC Devs, of course it would have been too good if everything was fine - it looks like the `ghc/ghc` repo currently does not update when pushing to it. I'm hoping to resolve this. Best Magnus

1 1

gitlab maintenance downtime starting soon
by Magnus Viernickel 11 Jul '26

11 Jul '26

Dear GHC Devs, This is your reminder that the announced GHC gitlab maintenance downtime will start soon. Best Magnus

1 0

GitLab availability update
by Magnus Viernickel 09 Jul '26

09 Jul '26

Dear GHC Devs, As you certainly noticed, the gitlab reliability started going again ca. 2 weeks ago. Already enacted changes improved the situations slightly (e.g. mitigated Anubis bypass) but not enough to make a smooth contributing experience possible. I am writing this mail to inform you about the following: 1. We will probably set most projects to `Internal`. This means that all projects where it's not important that they're publicly visible (like the main ghc/ghc repo) will be set to Internal, meaning they're only visible to logged in users. This will probably also affect your forks of GHC. 2. There will be a bigger gitlab outage this weekend Sat, 18:00 CEST (12:00 ET). We will give another go at upgrading our gitlab since that will allow us to do some prioritization of logged in users' traffic and this has been on our backlog for longer anyway. The downtime will be significant (multiple hours). During that time, you can change your upstream URL to github. The same is true for .gitmodules. 3. We will probably (if the infra team agrees) try out more aggressive defenses against bots since Anubis seems to not have the lasting effect we'd hoped. I am truly sorry this causes so much inconvenience for you and I hope we will be back to a usable state after the weekend. Best Magnus

1 0

Please don't use LLMs for my sake
by code＠jaro.addy.io 03 Jul '26

03 Jul '26

Friends, After some reflection, I feel the need to make it clear to everyone that I do not approve of LLMs (in their current state). I do not use them myself, but I also do not want the issues I open to cause others to use LLMs to help me, as seems to have been the case with #23173 (caused by me pushing for #27347). I would be delighted if we could all agree to a less laissez-faire "AI" policy in the future, but for now I simply wish to avoid inadvertently encouraging LLM use by others. Warm regards, Jaro

1 0

gitlab account trouble, and bug report
by Evan Laforge 03 Jul '26

03 Jul '26

Sorry to bother with gitlab administrivia, and please let me know if there's a better place to ask! I've been trying to file an issue at gitlab.haskell.org and having no luck. I'm pretty sure I had an account, and the browser remembers a password, but gitlab says it's invalid. Ok, fine, so I do forgot password, and it says if I have registered email it sent a reset... but didn't (checked spam etc.). Ok maybe it doesn't think I'm registered, so I try a new account and it says my email is already taken. At that point I'm a bit stuck, aside from creating a new email address specifically for this! So I suppose I'm not quite asking for account approval, but for either delete so I can recreate, or somehow unstick the reset password notifier, if that is in fact stuck. TIA for any assistance! Alternately, maybe someone could paste in the issue for me, though of course in the longer run I'd like to be able to file my own and maybe even help out if possible. Here's my description copied from haskell-cafe. This is a regression that started with 9.4 (presumably new recompilation avoider) and persists to the present day (well, 9.12.4 at least). Note that it only manifests when ghci is loading bytecode, but also has `.o` files around to load, so in the repro it's important to restart without -fobject-code. The -fobject-code is just imitating the build system, which would have created `.o` files for up-to-date sources: % cat >BugA.hs module BugA where x :: Int x = 13 % cat >BugB.hs module BugB where import qualified BugA f :: IO () f = print BugA.x % cat >BugC.hs module BugC where import qualified BugB bug :: IO () bug = BugB.f % ghci -fobject-code # compile so we can load .o GHCi, version 9.12.4: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/elaforge/qlib/dotfiles/.ghci Prelude> :load BugC [1 of 3] Compiling BugA ( BugA.hs, BugA.o ) [2 of 3] Compiling BugB ( BugB.hs, BugB.o ) [3 of 3] Compiling BugC ( BugC.hs, BugC.o ) Ok, three modules loaded. Leaving GHCi. % ghci Prelude> :load BugC Ok, three modules loaded. Prelude BugC> bug 13 As expected! Now go edit BugA.hs, and change 13 to say 14, and save. Now reload: Prelude BugC> :r [1 of 3] Compiling BugA ( BugA.hs, interpreted ) [Source file changed] Ok, three modules reloaded. Prelude BugC> bug 13 It has the old value! It should probably have reloaded BugB and BugC as bytecode, which is what 9.2 will do. Previously modifying a parent would force the graph in between the loaded module and the modified one to be reloaded as bytecode, ignoring the object code which is otherwise up to date. I don't know why exactly, previously I assumed BugB.o has stale values from BugA.o inlined, but leaving -fobject-code on just recompiles BugC and it works fine so maybe not!

1 0