Distinguishing between "pull-based" and "push-based" streams in Smalltalk makes no sense, because do: aBlock [self atEnd] whileFalse: [aBlock value: self next]. is in the same <gettableStream> protocol in the ANSI standard as #atEnd and #next, and in most Smalltalk systems it is in Stream. There should never be anything that has #atEnd and #next that doesn't have #do:. In some Smalltalk systems, Stream and Collection both inherit from a common superclass. In GNU Smalltalk, it's called Iterable, and provides, amongst other things stream1 , stream2 stream allSatisfy: filterBlock stream anySatisfy: filterBlock stream collect: transformBlock stream count: filterBlock stream detect: filterBlock stream detect: filterBlock ifNone: exceptionBlock stream do: actionBlock stream do: actionBlock separatedBy: separatorBlock stream fold: combinerBlock stream inject: initial into: combinerBlock stream noneSatisfy: filterBlock stream reject: filterBlock stream select: filterBlock My Smalltalk library does not do that, but it does have an Enumerable class that's somewhat similar (the distinction is that multiple traversal of a Collection must work, but only single traversal of an Enumerable is required), so readStream asEnumerable reject: filterBlock This makes about 257 Enumerable methods available. Combinators are good, but they should fit in with existing naming conventions. *Arbitrary* overloadings are a bad idea. The pipe "|" allows one to chain iterators - The ">" allows one to create a new collection with data transformed through chained iterators - The ">>" allows one to fill an existing collection with data transformed through chained iterators The vertical bar is used in Smalltalk for "or". It would make sense to have MonadicBlock methods for: 'combinators' | other ^[:x | (self value: x) | (other value: x)] and so on. Smalltalk already has a selector that means "concatenation", namely #, so stream1 , stream2 as in GNU Smalltalk would not be too confusing. Similarly, ">" means "greater than", and it would be deeply confusing to use it for some sort of data construction. We would expect stream1 > stream2 iff the future values of stream1 (as a sequence) are lexicographically greater than the future values of stream2 (as a sequence). Or you could argue for "the relative order of two streams is the relative order of their positions if the have the same underlying Collection or file system object, otherwise undefined".