… and a question to the community: do you find these reports useful? What would you like to see more or less about?
I read these reports religiously! It’s a great way to stay up-to-date on much behind-the-scenes work.
They are the best, I greatly enjoy reading them!
Absolutely. Always the first thing I read when I see them posted.
I, for one, also enjoy reading these reports. ![]()
I too read the reports with interest!
I would love to read a detailed article about the history of the coercion zapping work. Seems to have have been quite an odyssey! What was the final insight that managed to elicit a general improvement when the previous valiant efforts encountered one problematic corner case or another? To what degree was that insight gleaned and refined from the Fable-produced proof-of-concept, and to what degree that POC built upon the earlier efforts?
Agreed - being one of them type-level wizards, I’d love a good teardown of what went into to making this improvement!
Absolutely fantastic work on coercion zapping!
Hats off to Ben, Adam, Sam and Richard, who all had a go at it; to Sylvain, who got it unstuck with a tactical application of an LLM; and to Simon for reviewing and steering throughout.
Looking forward to seeing it in the next GHC release.
I found an item that is not GHC specific. Yay!
I love reading about activity in the GHC ecosystem, and I always look forward to the next report!
I think it would be great to have a small section about milestones and related issues that don’t currently have enough resources. It could inspire someone to pick one up and contribute
100%, I read each one, and also relay particularly interesting parts to my colleagues.
Thanks for the positive feedback and suggestions, everyone!
Regarding coercion zapping in particular, hopefully @shf and I will be able to find time to do a more detailed write-up. The gist of it is that it was “always” clear that zapping “should work” to massively improve compile-time performance in some (but clearly not all) cases involving type family heavy programs. But it turned out to be very easy to accidentally make performance regress in other cases. What was difficult was finding the right balance (in particular, determining precisely when and how to zap). As I understand it, @hsyl20’s Fable-produced proof of concept demonstrated that a balance was possible to achieve the improvements without the regressions, using some of the existing ideas plus at least one new idea (using a mutable variable to track the set of coercion variable dependencies, avoiding the need to ever force the coercion being zapped). That inspired @shf to make a fresh version and finish the job.