You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This would allow us to leverage the existing deforestation pipeline for pure values transformations.
We will likely need to generalize the stream implementation to support multiple input and output values at each step (in addition to zero or one). It should be usable in pipelines like (~> (-< (>< f) (>< g)) ...)
It's possible that a multi-valued stream implementation would be less performant than a single-valued one, but if it performs better than using pure values directly, then that is a worthwhile optimization. We need not use the same stream implementation for values as we do lists.
It may also be possible to extend stream fusion to other values-based combinators (in addition to ~>) like -<, ==, ><, if and pass.
The text was updated successfully, but these errors were encountered:
This makes me wonder about detecting (~> sep list-fuseable-values-steps collect) and list-fusing it, but that would really require knowledge of intermediate steps (like knowing that (>< user-func) is single-value output, maybe) to do.
Yeah, that's true. With something like #158 we should in principle be able to match certain special cases (where all functions are 1 × 1) to our existing deforestation pipeline. But the real challenge here in general is that user-func could return zero or more values rather than always one. I think when @dzoep first attempted to generalize our stream fusion implementation to multiple values, the performance dropped to be equivalent to naive Racket performance, so it wasn't viable for our deforestation of lists. But, given that values pipelines are likely much slower than lists, if we could handle this general case and have it perform as well as Racket lists, that would actually be a pretty great result. It could be a fallback in case better optimizations don't match.
How can we identify list-like operations done on values? See A Core Performance Issue Identified.
This would allow us to leverage the existing deforestation pipeline for pure values transformations.
We will likely need to generalize the stream implementation to support multiple input and output values at each step (in addition to zero or one). It should be usable in pipelines like
(~> (-< (>< f) (>< g)) ...)
It's possible that a multi-valued stream implementation would be less performant than a single-valued one, but if it performs better than using pure values directly, then that is a worthwhile optimization. We need not use the same stream implementation for values as we do lists.
It may also be possible to extend stream fusion to other values-based combinators (in addition to
~>
) like-<
,==
,><
,if
andpass
.The text was updated successfully, but these errors were encountered: