Thoughts:

• Moving Pull.uncons to Pull#uncons looks good, as does the optimization of the implementation.
• I'm neutral on changing new Stream(p) to p.streamNoScope.
• I don't like rewriting the internal recursive combinators to use Pull over Stream. The implementations use private APIs that users don't have access to, making it harder to learn from examples.

I don't like rewriting the internal recursive combinators to use Pull over Stream. The implementations use private APIs that users don't have access to, making it harder to learn from examples.

We can always publish those APIs, if they are useful enough.

I don't know if that's a good idea. Seems like a lot of churn API-wise (all the recursive pulls that would need to change to use a pull instead of stream argument). What's the benefit we get for that churn?

I don't know if that's a good idea. Seems like a lot of churn API-wise (all the recursive pulls that would need to change to use a pull instead of stream argument). What's the benefit we get for that churn?

Perhaps reducing the need for a second type wrapper, ToPull, in addition to the default Pull, but that may not be worth too many changes. Nevertheless, I will split this PR in twine later today.

the .uncons extension is nice :)
I'm a slight -1 on using streamNoScope over new Stream: it forces all readers to having to think about what a scope is, which arguably isn't necessary until much later on in their journey

I'm a slight -1 on using streamNoScope over new Stream: it forces all readers to having to think about what a scope is, which arguably isn't necessary until much later on in their journey

Perhaps we should rename them as stream and scopedStream, giving the more complex notion the longer name.

Edit or maybe, add a scoped method to the unit-pull, and make def stream just add the stream wrapper, so that

• Current .stream becomes .scoped.stream
• Current .streamNoScope becomes .stream.

I thought that introducing a scope is safer, and should be the default? At least that's the feeling I get from the scaladocs. In fact I feel like streamNoScope is the more complex notion, since I have to know when it's safe to not introduce a scope.