That is stop without returning a value and get the value by using final.
We need "Done b" in folds instead of "Stop" to know the termination without having to push the next input. We can potentially
change it to use a "Stop" constructor instead. With that we won't be able to know about the termination until we send the next element down the fold. And, in that case that last element would be unconsumed. This is similar to the "Stop" behavior on the stream side, where we don't know about the termination until we try to pull the next element. Also, with this we would be able to express "takeWhile" and "span" folds without an additional constructor which expresses the idea of not consuming the value. This also means that on "Stop" we will always have to call "final" to extract the fold result.
This will make the fold Step similar to Stream sans the "Yield" constructor.
This can also simplify the Scan Step and make it identical to the Stream Step.
That is stop without returning a value and get the value by using
final
.We need "Done b" in folds instead of "Stop" to know the termination without having to push the next input. We can potentially change it to use a "Stop" constructor instead. With that we won't be able to know about the termination until we send the next element down the fold. And, in that case that last element would be unconsumed. This is similar to the "Stop" behavior on the stream side, where we don't know about the termination until we try to pull the next element. Also, with this we would be able to express "takeWhile" and "span" folds without an additional constructor which expresses the idea of not consuming the value. This also means that on "Stop" we will always have to call "final" to extract the fold result.
This will make the fold Step similar to Stream sans the "Yield" constructor.
This can also simplify the
Scan
Step and make it identical to the Stream Step.