August 2026 - ghc-devs

GHC LLM policy vs copyright
by damiancoding＠gmail.com 11 Aug '26

11 Aug '26

Dear all, I have thus far been perusing the LLM policy discussion from the bleachers. A lot of conversation has been had about the ethical and practical reasons to support or abolish LLM use for GHC. However, one really important point seems to have been all but omitted from the conversation, and that is the legal aspect. GHC, like any other project using any licensing at all, enjoys protections based in the legal system of every country it is being used and developed in. That is no small thing and is essentially what allows GHC to exist in the legal sense. A body of work untethered from this is like a person without citizenship - no one will advocate for it, and no government will back up legitimate claims around it by enforcing laws and regulations. It is the contention of some legal scholars that having a significant (not large or overwhelming, merely significant) amount of AI based contributions in a body of work can lead to lack of recognition of its copyright in court. This opinion is already backed up by case law relating to art: https://www.theverge.com/policy/887678/supreme-court-ai-art-copyright Such a status would put the project's protections in danger legally and could turn to foil the efforts of GHC contributors over the past numerous years. Of course, art is not code, and I would say many people's code is not art... but absence of proof is not proof of absence. This is merely legal limbo, not legal certainty, and early indications suggest the tree may fall on the house. In fact, who is to say that at least in some jurisdictions, AI companies couldn't go rogue and turn around and say anything that's been generated does not belong to you intellectually - it belongs to the model, and therefore to its owner, the AI company? Of course, there are explainers and assurances, but none of this is legally tested. As someone who has advised on, joined, and started lawsuits in more than a handful different legal systems, I can tell you that they are all very idiosyncratic and there is no common-sense to any of them. Local law can be extremely surprising and in fact one place's laws can contradict another place's laws. There are also secondary effects as well. For example, can you get public funding for such a project? Can you be recommended by government entities and various organizations? Can you use or contribute to such work as a university employee, researcher, or student? This last one is particularly important for a project that lives and dies by the ability of researchers to contribute to it. I may have simply missed it in the deluge, but I have found that there has been little to no discussion of the effect of LLM contributions on the copyright of GHC. Perhaps before entering this "Brave New World", we should see if the ice is too thin to walk on. Especially during war time, there has been a multitude of legal documents that were proof of citizenship to one area or another. Sometimes they looked like the blue British passport that is all the rage these days, sometimes they were a tattered piece of paper in an envelope of you were lucky, with nothing more to certify its authenticity than a stamp, and a block-letter name written by someone who barely ever held a pen, at an outpost in the deep forest. This may have been all that a person, coming from a country that may not even exist anymore due to changes in war, has to go on for legal recognition as a citizen of any country. Many times such documents were ad-hoc or provisional and there wasn't even a way to check them for authenticity or correctness, if the checking was being done by a person a thousand miles away from the document's origin and who is not even able to read the alphabet let alone the language. Very often such documents would not be recognized; it was as much dependent on the politics of the day (does the Soviet Union recognize the Croatians?) as on whether you had a pack of cigarettes to share with the militia man patrolling the path you were on. A solid passport from a powerful country got you out of trouble. The legal system around LLM contributions is changing. Very little of it is proven and what has been proven so far shows that they enjoy no protection. For better or worse whatever imaginary lines on the ground we imagine and agree upon within our little tribe will be completely disregarded and obliterated by the machine of war that sets out the order as the legal system solidifies. To understand how this can lead to disappointment, just ask people in Finland whether they are nostalgic for their lost territory. I believe the integration of LLM based output into GHC is an issue that requires prudence far beyond "community consensus", "robust conversations", and "good proposals". It can clearly have ramifications of legal, compliance, civic, policy, and otherwise government-related nature, should be treated seriously as such, and therefore the project should source informed analysis and recommendation from those whose job it is to do so. This in particular means we should be hiring and listening to impartial professionals and not sounding off as developers who don't know the first thing about such matters. I say all this as someone who uses AI on the daily and has worked at a frontier AI lab that has been acquired by interests related to the US government. I think GHC is more important than being able to work on it with specific techniques. Everyone employing asbestos had the best intentions and could never have known where it would lead, but out of this period in history we have learned to be careful about employing new technology. Currently, the only people talking about this on this list are asbestos users and carpenters, and no one's thought to ask the doctors or physicists. With best regards, Damian

5 16

Home Improvement
by charlotte＠tapron.ie 10 Aug '26

10 Aug '26

Tapron Ireland offers stylish taps, showers and bathroom fittings designed for practical, elegant interiors. https://tapron.ie/

1 0

ghc handbook
by Sasha Bogicevic 10 Aug '26

10 Aug '26

Hey all, I wanted to share ghc handbook I made using AI https://devnull-org.github.io/ghc-handbook/ I know people have opposite views when it comes to AI usage but I believe using AI to learn things is really poweful. This page might help interested haskell programmers to explore ghc internals. Not sure how useful it is for people already knowledgable about ghc but at least the ghc notes are easy to access. Anyway, hope this attracts new people to do some work on the compiler, please let me know what you think or if anybody is interested in reviewing the content. This is just the first draft so future versions should be better. Thanks, Sasha PGP 6023d9e35e208decad5101f0be284d15ea8108a2 Sent from Proton Mail for iOS.

4 6

report from the gitlab front
by Magnus Viernickel 07 Aug '26

07 Aug '26

Dear GHC Devs, I have some interesting information to share with you. You might have noticed that our gitlab was a bit more swamped the recent days again and today I investigated and discovered that Anubis was getting bypassed by requests with a new user agent that I haven't seen before, "Lightpanda/1.0". Normally, anubis checks for user agents that are known bot user agents and blocks them; Lightpanda was left unblocked because Anubis only filtered for LightPanda (capital p). This is normally not a problem because most crawlers try to use user agents that look like browsers; if you're using a browser user agent, you're getting a higher weight and you get presented as challenge; but you're also much harder to sift out because you look benign. While the amount of requests we were getting with that user agent had reached absurd dimensions, this was also a blessing. First of all, it was easy to ban it and reduce the gitlab load drastically. Second, now we could run an analysis on who is using these malicious clients. Xe, the creator of Anubis kindly provided me with a tool that qualitatively (based on unique IP addresses, disregarding hits per IP) puts IP addresses in buckets based on several known factors, e.g. location or the ASN (which entity the IP address block is delegated to). The results can be seen here: https://gitlab.haskell.org/-/snippets/6132 A few noteworthy things: - 1.4 Million distinct IPv4 addresses have been used with this bot user agent - the IP addresses stem from 225 different countries. I think we have ~ 30 more distinct ISO country codes. - we have some known faces! like spacex which got flagged 100% time on their 21000 distinct IP addresses they're using to DDoS us - we also have quite a lot of domestic use ASNs, which indicates that botnets are involved, too! - Xe noted, that we can proudly say this counts as a DDoS Mind that this does not include all the spammers that are actually trying to hide the fact that they're spammers, which still exist. Also mind that this was just the data from ~1 day of logs. I hope this gives a nice sense of what we're dealing with and maybe it also helps with your frustration to see my frustration and the fact that we're sometimes getting little wins. Like today. Best Magnus

3 2

CI issue resolved
by Magnus Viernickel 06 Aug '26

06 Aug '26

Hi GHC Devs, we had CI failing this morning pretty badly. This issue should be resolved. Please excuse the troubles; you may restart your CI runs. If you have issue with any CI runner, please contact me. Best Magnus

1 0

Help Diagnosing 9.14.1 compiler "crash"
by Justin Bailey 05 Aug '26

05 Aug '26

All, Looking for some guidance on narrowing down an issue I am seeing at work. Some background: large monorepo, many packages; I'm on MacOS Tahoe (26.6). I have a problematic module that causes GHC to allocate a HUGE amount of memory under certain conditions. Compilation never finishes - instead, the process is killed by the OS. * With -O1, GHC consumes a huge amount of memory (> 32GB) before getting killed by the OS. * Without -O1, but with all available -f flags that seemed to be implied by -O1, GHC does NOT blow up and compilation succeeds. (List of flags below.) The last output (with -ddump-phases) in the failing case is always "*** Specialise [aaa.Tests.Service.Client.TestHelpers]:" followed by a newline, then nothing else. I'm working to isolate the code that's causing the problem, to get to a repro case, but in the meantime can anyone suggest why -O1 fails but all the -f flags do not? Thank you! p.s. I'm happy to share logs but don't want to spam the list if those aren't necessary. ********** Here are all the flags I used in place of -O1: -fblock-layout-cfg -fcall-arity -fcase-folding -fcase-merge -fcore-constant-folding -fcmm-control-flow -fcmm-elim-common-blocks -fcmm-sink -fcmm-static-pred -fcore-constant-folding -fcpr-anal -fcross-module-specialise -fcse -fenable-rewrite-rules -fexitification -ffloat-in -ffull-laziness -fignore-asserts -finline-generics -floopification -fnum-constant-folding -fsolve-constant-dicts -fspecialise -fstg-cse -fstrictness -funbox-small-strict-fields -fworker-wrapper ********** Here is the (possibly) relevant logs for compilation with -O1 that failed: *** Checking old interface for aaa.Tests.Service.Client.TestHelpers (use -ddump-hi-diffs for more details): [62 of 74] Compiling aaa.Tests.Service.Client.TestHelpers ( test/aaa/Tests/Service/Client/TestHelpers.hs, /Users/xxx.yyy/Source/health-engine/well-he-aaa/worktrees/master/dist-newstyle/build/aarch64-osx/ghc-9.14.1/aaa-service-client-0.0.0/t/test/noopt/build/test/test-tmp/aaa/Tests/Service/Client/TestHelpers.o, /Users/xxx.yyy/Source/health-engine/well-he-aaa/worktrees/master/dist-newstyle/build/aarch64-osx/ghc-9.14.1/aaa-service-client-0.0.0/t/test/noopt/build/test/test-tmp/aaa/Tests/Service/Client/TestHelpers.dyn_o ) *** Parser [aaa.Tests.Service.Client.TestHelpers]: !!! Parser [aaa.Tests.Service.Client.TestHelpers]: finished in 7.28 milliseconds, allocated 2.470 megabytes *** Renamer/typechecker [aaa.Tests.Service.Client.TestHelpers]: *** ConsistencyCheck [aaa.Tests.Service.Client.TestHelpers]: !!! ConsistencyCheck [aaa.Tests.Service.Client.TestHelpers]: finished in 1763.61 milliseconds, allocated 750.592 megabytes !!! Renamer/typechecker [aaa.Tests.Service.Client.TestHelpers]: finished in 2449.36 milliseconds, allocated 962.845 megabytes *** Desugar [aaa.Tests.Service.Client.TestHelpers]: Result size of Desugar (before optimization) = {terms: 713, types: 33,167, coercions: 15,521, joins: 0/171} Result size of Desugar (after optimization) = {terms: 551, types: 27,957, coercions: 15,828, joins: 0/93} !!! Desugar [aaa.Tests.Service.Client.TestHelpers]: finished in 5.46 milliseconds, allocated 2.524 megabytes *** Simplifier [aaa.Tests.Service.Client.TestHelpers]: Result size of Simplifier iteration=1 = {terms: 2,677, types: 74,181, coercions: 37,908, joins: 0/155} Result size of Simplifier iteration=2 = {terms: 1,737, types: 52,195, coercions: 27,615, joins: 0/88} Result size of Simplifier iteration=3 = {terms: 1,673, types: 51,005, coercions: 19,466, joins: 0/80} Result size of Simplifier iteration=4 = {terms: 1,630, types: 50,531, coercions: 19,333, joins: 0/78} Result size of Simplifier = {terms: 1,630, types: 50,531, coercions: 19,333, joins: 0/78} !!! Simplifier [aaa.Tests.Service.Client.TestHelpers]: finished in 217.38 milliseconds, allocated 120.723 megabytes *** Specialise [aaa.Tests.Service.Client.TestHelpers]: ********** Here are those same logs (up to specialisation) for a compilation that succeeded (no -O1, only the -f flags): *** Checking old interface for aaa.Tests.Service.Client.TestHelpers (use -ddump-hi-diffs for more details): [62 of 74] Compiling aaa.Tests.Service.Client.TestHelpers ( test/aaa/Tests/Service/Client/TestHelpers.hs, /Users/xxx.yyy/Source/health-engine/well-he-aaa/worktrees/master/dist-newstyle/build/aarch64-osx/ghc-9.14.1/aaa-service-client-0.0.0/t/test/noopt/build/test/test-tmp/aaa/Tests/Service/Client/TestHelpers.o, /Users/xxx.yyy/Source/health-engine/well-he-aaa/worktrees/master/dist-newstyle/build/aarch64-osx/ghc-9.14.1/aaa-service-client-0.0.0/t/test/noopt/build/test/test-tmp/aaa/Tests/Service/Client/TestHelpers.dyn_o ) *** Parser [aaa.Tests.Service.Client.TestHelpers]: !!! Parser [aaa.Tests.Service.Client.TestHelpers]: finished in 5.70 milliseconds, allocated 2.470 megabytes *** Renamer/typechecker [aaa.Tests.Service.Client.TestHelpers]: *** ConsistencyCheck [aaa.Tests.Service.Client.TestHelpers]: !!! ConsistencyCheck [aaa.Tests.Service.Client.TestHelpers]: finished in 1707.88 milliseconds, allocated 749.094 megabytes !!! Renamer/typechecker [aaa.Tests.Service.Client.TestHelpers]: finished in 2305.51 milliseconds, allocated 959.358 megabytes *** Desugar [aaa.Tests.Service.Client.TestHelpers]: Result size of Desugar (before optimization) = {terms: 713, types: 33,167, coercions: 15,521, joins: 0/171} Result size of Desugar (after optimization) = {terms: 551, types: 27,957, coercions: 15,828, joins: 0/93} !!! Desugar [aaa.Tests.Service.Client.TestHelpers]: finished in 4.66 milliseconds, allocated 2.526 megabytes *** Simplifier [aaa.Tests.Service.Client.TestHelpers]: Result size of Simplifier iteration=1 = {terms: 555, types: 27,953, coercions: 15,828, joins: 0/93} Result size of Simplifier = {terms: 555, types: 27,953, coercions: 15,828, joins: 0/93} !!! Simplifier [aaa.Tests.Service.Client.TestHelpers]: finished in 8.60 milliseconds, allocated 5.818 megabytes *** Specialise [aaa.Tests.Service.Client.TestHelpers]: Result size of Specialise = {terms: 555, types: 27,953, coercions: 15,828, joins: 0/10} !!! Specialise [aaa.Tests.Service.Client.TestHelpers]: finished in 3.98 milliseconds, allocated 2.227 megabytes

2 3

A shared statement on our environment in the face of LLMs
by Moritz Angermann 05 Aug '26

05 Aug '26

Dear friends, I've spent the last two days discussing the topic of LLM contributions in detail with Julian at length over video. As the discussion over the last few weeks have shown that it's very hard to find agreement on a common policy, we have tried to outline what we consider a statement that covers at least both of our views. With Julian and I representing a fairly wide spectrum of the positions, we hope that this may provide a statement that many can subscribe to. We have tried to keep it short, and not get distracted by specificies of workflows, quality standards, and definitions of terms, which seem to distract from the core that we want to address. Respectfully, Julian and Moritz ## A shared statement on our environment in the face of LLMs As human-LLM interaction is becoming more common, we find ourselves debating not only our technical goals, but also our understanding of open source community and values. This is why we all agree that we want to participate in an environment... 1. that inspires the exchange of technical ideas and knowledge between humans 2. that is supportive and accessible to the point that no one should feel the need to use LLM in the first place 3. that facilitates building trust relationships with one another 4. that rewards technical excellence and authenticity 5. that demands all interactions to be genuine and respectful We recognize that using LLMs responsibly is challenging. Not only can they be used for abuse[^1][^2], but they may also cause the quality of communication and intellectual engagement to decline[^3]. There is an emerging body of scientific literature supporting these concerns about negative effects on psychological, cognitive, real-world performance, etc. We recommend everyone to familiarize themselves with the current state of research. Here are a few links for your consideration. * [How AI Impacts Skill Formation](https://arxiv.org/abs/2601.20245) * [AI Assistance Reduces Persistence and Hurts Independent Performance](https://arxiv.org/abs/2604.04721) * [From Future of Work to Future of Workers: Addressing Asymptomatic AI Harms for Dignified Human-AI Interaction](https://arxiv.org/abs/2601.21920) * [AI Competency Erosion: Understanding Expertise Decay](https://link.springer.com/chapter/10.1007/978-3-032-11748-9_5) * [Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task](https://arxiv.org/abs/2506.08872) * [Investigating the Effects of LLM Use on Critical Thinking Under Time Constraints: Access Timing and Time Availability](https://arxiv.org/abs/2603.08849) _(This list does not claim to be comprehensive; it is merely meant to provide you with an initial stepping stone into the current research)._ Moreover we are especially concerned about their potential negative effects on open source communities[^4], human communication and collaboration. We strive to be an inclusive community and judge contributions on their merits. This includes the use of LLMs as long as it does not disturb our envisioned environment outlined earlier. We recognize that there are users and contributors of this project who would rather not interact with LLM generated content at all. To balance the preferences and self-determination of the diverse group of contributors, we require that the use of LLMs to generate content is clearly attributed as such, failure to do so may result in contributions to be rejected. We understand that this may not be satisfactory to everyone, since we cannot completely avoid exposure to LLM generated content. However, we will neither compromise our quality standards, nor allow any disruption of human-human interaction by the use of technology. Examples of inappropriate use are: - feeding someone's email into an LLM to generate an answer - creating automated LLMs written bug reports that a volunteer has to work through to determine if it has any value at all - generating large patches that take more time to review by the project than it took you to create We want this to be a project of human interaction, of shared curiosity and a beacon of engineering excellence. These are the shared values we stand by today as a project, and they may evolve along with our shared experiences and emerging scientific evidence over time. Julian Ospald Moritz Angermann -- [^1]: https://openai.com/index/disrupting-malicious-ai-uses/ [^2]: https://www.infoq.com/news/2026/02/ai-floods-close-projects/ [^3]: https://arxiv.org/abs/2506.06166 [^4]: https://arxiv.org/abs/2601.15494

6 11

Unable to create personal access token at gitlab.haskell.org
by Eric 04 Aug '26

04 Aug '26

Hi all, In order to fetch and checkout a branch of my fork of GHC, I am trying to create a personal access token which I would use as a password at the command line. However, when I try to add a new token, the page hangs displaying a the "please wait" circle graphic. Does anyone know what might be wrong? Regards, Eric

3 2

Re: GHC LLM policy take 2
by Tom Ellis 03 Aug '26

03 Aug '26

On Wed, Jul 29, 2026 at 12:42:45PM +0000, code(a)jaro.addy.io wrote: > > On 29 Jul 2026, at 14:24, Tom Ellis via ghc-devs <tom-lists-ghc-devs-2026(a)jaguarpaw.co.uk> wrote: > > Perhaps, or perhaps people use a better, but more expensive, model > > less? > > I expect most people to use a subscription like Claude Max or OpenAI > Pro, which encourages using as much as the plan allows. Subscriptions typically come with a number of credits that refresh every so often. More expensive models use more credits. Subscription use is not "unlimited". https://help.openai.com/en/articles/12642688-using-credits-for-flexible-usa… Tom

9 20

Re: LLM-generated code review as a service
by Simon Jakobi 03 Aug '26

03 Aug '26

Moritz, let me loop in the mailing list again. I understand that my service really doesn't have the value of a proper human code review. However, judging from my private trial runs, it does seem to catch bugs that neither the testsuite nor human reviewers caught. MR authors could of course use LLMs themselves to find the same bugs, but this doesn't seem to be widespread practice yet. Potential reasons for this: cost or lack of access for other reasons, insufficient quality of the review output. I also agree that there is a potential risk that my service could reduce the current human review practice. My suggestion would be to make a small survey in three months or so where we evaluate how my service affects this project, including the social interactions. Potential tweaks on how to use this service: * MR authors can request a private review for their draft MRs in order to catch issues before human reviewers spend time on them. * Only once the "human review" has concluded, we do a second GlaHiCo run, and the result is shared publicly on the MR. Does this sound better to you? Best, Simon Am Do., 30. Juli 2026 um 02:38 Uhr schrieb Moritz Angermann <moritz.angermann(a)gmail.com>: > > Hi Simon, > > I want to highlight the following: >> >> >> 1. The information in the review is intended for all people who are involved in an MR: Both authors and reviewers. > > > I personally find this to be straddling the line where we force exclusively LLM generated content on others and it starts to blur the line between where the human is. > > If a human receives (on request) a LLM review, treats it as probabilistic text output, and reviews the review for potential useful highlight, and then selectively makes those highlights their own before fixing them themselves or discussing them with others has a qualitatively difference to “look at the LLM generated review at <url>.” The latter one (at least to me), comes across as lacking respect towards others. > > If you use a tool to perform a review, I don’t really care, this is your agency, your freedom to do as you please, but if you pass this off to me as: here look at this output an llm generated, instead of reading the output making it your own and then passing it on as your own with your own comments, … who is it with whom I interact? > Why don’t I instead just ask the llm myself? > > > Now if everyone agrees that they want to collectively ask a llm, sure. Even though I do use LLMs, I wouldn’t want unedited llm output pass on to me. There is no value in that to me; I can do that myself. I want to interact with humans and their ideas, intellect and curiosity. > > It’s the same fundamental conflict I have wirh coderabbit and copilot reviews. I find them intellectually exceptionally boring. Distracting even. And having them in PR discussions (especially as comments like on GitHub), I feel myself losing interest extremely quickly. This is distinctly different from me using a LLM on the side as assertive tool to support my understanding, and form my opinion (and maybe word choice) when writing a comment. > > My primary concern is that while I’m perfectly ok with using LLMs, this opens the door towards verbatim llm output as a normalized way to interact with others; something which I oppose. > > Best, > Moritz > >> >> Am Mo., 27. Juli 2026 um 19:38 Uhr schrieb Simon Jakobi >> <simon.jakobi(a)gmail.com>: >> > >> > Hi devs! >> > >> > Inspired by the recent discussion on the LLM policy, I'd like to try >> > introducing LLM-generated code reviews in GHC, as an opt-in service. >> > >> > My motivation: >> > >> > * Catch issues before human reviewers spend time on them. >> > * Reduce the number of bugs merged. >> > >> > >> > What this is — and what it isn't >> > -------------------------------- >> > >> > This is tool output: requested on the MR, produced by a model, posted verbatim >> > and clearly marked as machine-generated. This is not a review in the sense of >> > draft LLM policy. >> > >> > I'm not vouching for any of it. Think of it as a linter the author could have >> > run themselves, except on my LLM budget. Nobody is required to act on >> > it even read it. >> > >> > I mention this explicitly because the policy asks reviewers to take full >> > responsibility for each line of their review. I can't do that here — it would >> > mean checking every finding myself, which defeats the purpose and would >> > restrict the service to areas of the compiler I already know well. >> > >> > >> > How to request one >> > ------------------ >> > >> > * Ping me on the MR with a comment like "@sjakobi llm-review please". >> > * Feel free to request particular aspects the review should cover. >> > * Authors can request a review for their own MRs. Maintainers can request one >> > on any MR. >> > * If I have enough usage left on my plan, I'll confirm that I'm on it. >> > * I'll then prompt the model, and post the result on the MR. >> > * Feedback on the quality of the review is of course very welcome. >> > >> > >> > What I promise >> > -------------- >> > >> > * Every review is labelled as machine-generated, with model, effort level and >> > the exact prompt used. >> > * Reviews are posted verbatim. I don't edit or curate them, so what you see is >> > exactly what the model produced. >> > * Only the public MR diff and public repository context go to the model. >> > Nothing else. >> > * I'll keep working on the prompts and the choice of model to improve the >> > signal-to-noise ratio. >> > * If the signal-to-noise ratio stays inacceptably bad, we can simply >> > stop this service. >> > >> > >> > Review coverage >> > --------------- >> > >> > I'll probably start with a fairly basic review prompt, primarily aimed at >> > correctness issues. >> > >> > Possible extensions: >> > >> > * Documentation consistency: check that documentation stays consistent, >> > including Notes elsewhere that reference the changed code. >> > * Performance: check for performance issues — potentially including checking >> > the -ddump-simpl output for the changed code for unnecessary >> > allocation etc. >> > * Feel free to suggest anything else! >> > >> > >> > Format >> > ------ >> > >> > Initially a single comment per review. Once we reach a good signal-to-noise >> > ratio, we can consider inline comments on the diff. >> > >> > >> > Caveats >> > ------- >> > >> > This is a volunteer service I intend to provide in my spare time. If I'm AFK >> > or on vacation, reviews will take longer. If I can't keep up with requests, I >> > will prioritise which MRs I run. I might take a break entirely. >> > >> > >> > Getting involved >> > ---------------- >> > >> > Is anyone interested in joining this effort? If so we could form a team >> > (@llm-reviewers?), and share prompting techniques, model choices, etc. >> > >> > If the service turns out to be genuinely useful, we can look into >> > automating it and – if necessary – possible funding. >> > >> > >> > Cheers, >> > Simon >> _______________________________________________ >> ghc-devs mailing list -- ghc-devs(a)haskell.org >> To unsubscribe send an email to ghc-devs-leave(a)haskell.org

2 2