Re: Feedback request regarding HSOC project (bringing sanity to the GHC performance test-suite)

Phyx writes: [snip] Hi Phyx, Sorry for the late reply here; Jared did a good job of summarizing the effort. I just want to make sure that we clearly put this particular concern to rest: > This would be unfortunate as it would mean we would effectively stop > tracking

RE: Overapproximation of loopbreakers due to unfoldings

INLINE means "Inline what I wrote". So in your example we'd have ===> bindWith [INLINE = ] = bindWith_abc |> co bindWith_abc = If you see a call to bindWith, we will /not/ inline bindWith_abc |> co! We'll inline . That's what the programmer asked for.

Re: A type checker plugin for row types

Hello Simon! Thanks for taking a look. I've attempted to address your Core question by adding a new section to the wiki page: https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/RowTypes/Coxswain#SomeLightCoreSnorkeling Regarding the necessary EvTerms, I haven't thought through that enough

Overapproximation of loopbreakers due to unfoldings

I have been puzzling over the example presented by Harendra in #14211 for the last two days. Ultimately it led me to discover that if a self-recursive definition is marked with an INLINE pragma then it will always be marked as a loopbreaker. This is undesirable in this case as the simplifier

RE: A type checker plugin for row types

Nick Good work! You ask some questions about the constraint solver – I hope that the answer from others have helped. If not, do re-ask. My main comment is: what does Core look like? I think your answer is “No change to Core, but there are lots of unsafe coerces littered around”. But even