Hi Tom! Am Fr., 24. Juli 2026 um 11:09 Uhr schrieb <amindfv@mailbox.org>:
On 07/24/2026 10:12 AM CEST Simon Jakobi via ghc-devs <ghc-devs@haskell.org> wrote:
A beautiful code base
I wonder if this principle should be balanced with the goal of trying to make a "good compiler": a good tool which is "a joy to use". Specifically I'm thinking about some compiler performance challenges where a pragmatic solution comes at the expense of code elegance: I'm probably overthinking this, but I'd like to avoid a situation where someone points at these principles and says "We can't accept these performance improvements because they make the code less beautiful."
I might be slightly misremembering history here, but I think this has already happened in the past. I recall discussion of a new register allocator(?) that was indeed faster, but much more complex and fiddly. The decision was made to stick with the somewhat-less-efficient "obviously no defects" version, vs. the "no obvious defects" one. In other words, elegance and comprehensibility (by humans) are sometimes as valuable as raw speed.
It should not be a no-brainer that any code change which passes its tests and improves performance must be merged in. A discovery of potential speedup is of course very valuable, but it then needs to be integrated into the way GHC works (including how its human developers' brains work).
I agree that there should be a balance. The current wording just seems unbalanced towards beautiful code.
If you are reviewing an MR, and any part(s) of your review are generated by an LLM, you should use essentially the same guidelines as above. That is, you must take responsibility for every line of your review (P2);
So I think that it would be worth experimenting with LLM-generated reviews, in order to reduce the load on human reviewers and in order to catch more bugs and performance issues before they make it into the code base. But if we require that the person who prompts the review and reports it on the MR has to take full responsibility for that review, I think that such an experiment is unlikely to stand a chance. In particular, the person providing the review would then probably be required to understand the generated review, and possibly the MR too. As a consequence we would be less likely to get LLM-generated reviews on the more complex MRs where they could be particularly helpful.
I'm not sure if there have been any problems with LLM-generated reviews so far? My suggestion would be to drop the responsibility requirement for clearly marked LLM-generated MR reviews.
Am I reading you correctly that your suggestion is to have code reviews where no human takes full responsibility for the review?
Yes. I think this could be an effective way to reduce the workload on human reviewers and to reduce the number of bugs and perf issues introduced into GHC. My intention is not to replace human review, but to filter out some of the problems with a code contribution before a human reviewer spends their time on it.
R1 [...] (P2) says that you should take full responsibility for your entire contribution. It is certainly possible to do so by forensically reviewing and revising the output of an LLM, checking that you understand and stand by every line of code, **that there is no clearer or simpler way to achieve the goal; and that every sentence of documentation is accurate, necessary, clear, and fully yours.**
(emphasis mine)
These criteria seem to set the bar very high, and I'm pretty sure that there have been multiple contributions that didn't involve LLMs and that failed to satisfy these criteria, so it seems a bit unfair to impose them now and only on LLM-generated contributions.
When a human makes a statement that they tried their best to be accurate, yet wasn't, that's a great opportunity for a reviewer to transfer knowledge to another person. If an LLM hallucinates, that's purely wasted reviewer time (a precious resource!) with no upside at all. It makes sense that good-faith human mistakes would be treated differently than AI hallucinations.
I guess you have a point there.
The undertone I'm getting is "If you make an LLM-generated contribution and it's less than absolutely perfect, you're a bad LLM-jockey and you should feel bad." IMHO this just deters possible contributors, so maybe this paragraph can be toned down a bit for now.
Stepping back for a moment, I find it interesting that the current revision, which seems to have ceded any mention of preference for human-written code, is still seen as too anti-LLM, and the request is to lower the bar even further ("These criteria seem to set the bar very high").
I think the preference for human-written code is still expressed implicitly but loudly in R1.
I'm straining to see how SPJ of all people would make a statement like "you're a bad LLM-jockey and you should feel bad."
Hmm, I'm afraid this "undertone" was mostly my own insecurities speaking. ;) I certainly did not intend to imply that Simon PJ would say anything like that.
If the policy turns out to be insufficient to stop the slop, we can still strengthen the requirements.
That's the crux of the issue, though, right? "Insufficient to stop the slop" is in the eye of the beholder. Currently 50% of "voters" on the GHC GitLab feel that _any_ LLM usage is inappropriate. I think it would be valuable to consider how to make a policy that doesn't just please the people who want to use LLMs without too high of a quality bar, but also recognizes that when a person makes an LLM contribution to the GHC GitLab, more than* half of the users there are thinking "I wish you hadn't done that."
I don't think the voters on that issue are a very representative group that this policy should be optimized for. Cheers, Simon