> On 07/24/2026 10:12 AM CEST Simon Jakobi via ghc-devs <[email protected]>
> 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).
> > 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?
> > 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.
> 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'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."
> 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."
Cheers,
Tom
*I say "more than" because 50% want to ban it entirely. There are others who
would prefer it not be used, but don't want to force their preferences in the
form of a ban.
_______________________________________________
ghc-devs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
