On Tue, 9 Dec 2025 at 18:56, Sebastian Graf <[email protected]> wrote:
> We want the same for stream fusion because it has better fusion support for > `zipWith`. Inlining any function involving `Step` is absolutely the right > thing to do! Aggressive specialization as well, but that's really difficult > to do using SpecConstr because it blows up so easily. Yes, exactly. In the vector stream type, the state of the stream is exposed, so we can compose the states and step functions of multiple streams to create a combined, fused step. This enables producer-producer fusion e.g. zipWith or mergeBy can be fused. foldr/build only supports producer-consumer fusion and cannot support producer-producer fusion because the producer does not expose its internal state. Yes, SpecConstr can blow up especially when the state type is too big or is recursively defined. In practice the problematic case we have seen is when the state contains a list, because lists have unbounded structure and SpecConstr can try to specialize for many argument patterns when we are using something like -fspec-constr-recursive=16. We disabled SpecConstr in that situation to avoid code size explosion. > TLDR; inlining and specialising `Step` sounds like exactly what is needed. > Specialisation of concatMap is the hard part for stream fusion, though, and > that means we'll end up with `Step` in the program nonetheless. We do not try to fuse concatMap, instead we recommend another fusible abstraction for loop nesting which is the Unfold type in streamly and related operations like unfoldEach. That is the right way to achieve nested loop fusion, with that we get fully fused nested stream code. It is not as powerful as concatMap but in most common cases we do not need that additional power of concatMap. If you really need the full power of concatMap, you cannot expect the same performance, because fully general concatMap fusion is not achievable without losing fusion or causing excessive specialization. -harendra _______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
