Hi Tom!
Am Fr., 24. Juli 2026 um 11:09 Uhr schrieb <[email protected]>:
>
> > 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).
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
_______________________________________________
ghc-devs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
