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".
