It’s totally possible to write benchmarks or inspection testing that would require heavy (e.g. whole-program) optimization. You’re assuming that all Haskell will always exhibit GHC’s limitations.
So no, you cannot guarantee people will pay a runtime cost for something that is testable and preventable before runtime.
But ~danso’s example is great because it’s megamorphic depending on the runtime value of n, so there isn’t a reasonable way to monomorphize it even for a compiler like jhc.
I understand it’s a difficult case, but if it is pathological, wouldn’t we be using a outlier to generalize from, it we pretended that this program needs optimization? If these programs are very rare. I suppose it all rests on what “code like this” means…
I don’t believe e.g. Haskell typeclass instances can always be monomorphised:
pathological :: (Show t) => (Integer, t) -> String pathological = \case (0,x) -> show x (n,x) -> pathological (n-1,(x,x))Anybody who writes code like this is going to pay a cost in runtime performance, one way or another.
score 2 · canonical
It’s totally possible to write benchmarks or inspection testing that would require heavy (e.g. whole-program) optimization. You’re assuming that all Haskell will always exhibit GHC’s limitations.
So no, you cannot guarantee people will pay a runtime cost for something that is testable and preventable before runtime.
score 1 · canonical
But ~danso’s example is great because it’s megamorphic depending on the runtime value of n, so there isn’t a reasonable way to monomorphize it even for a compiler like jhc.
score 1 · canonical
I understand it’s a difficult case, but if it is pathological, wouldn’t we be using a outlier to generalize from, it we pretended that this program needs optimization? If these programs are very rare. I suppose it all rests on what “code like this” means…
score 1 · canonical