Sorry, I couldn't read my mail the last week or so, but now I'm 'back in
business' :-)

I hope to find some time to have a more thorough look at your stuff, but
this sounds a lot like the nested lazy streams I use in the previous
implementation of SOUL. These streams are created as wrappers around
existing collections or use a general block to define whatever you want
(such as infinite streams of numbers etc.). Then you can enumerate these
streams (such as asking for elements one at a time, or trying to get all
elements, etc.). But of course, this is still very basic. Like you
mentioned, you also want to be able to define a new stream as some operation
over the elements of another stream (like a map in functional programming),
for example to created a 'square numbers' stream. Besides this, I also have
a special stream that wraps to streams and combines their elements according
to a block. All computation is lazy: whenever you ask for a next element,
only the necessary elemenents are calculated. I used this to implement the
logic interpretation of SOUL in a more or less functional fashion, just
because it was easy to do.

Note that this implementation with streams is now replaced in the squeak
implementation of SOUL by a stack-based version implemented by Johan Brichau
and other people at PROG. This speeds up the logic interpretation, because
it's more efficient to implement it with a stack, but bot nearly as much fun
:-)


On 16/06/01 22:51, "Brian Rice" <water at tunes.org> wrote:

> Hi Roel and Squeakers,
> I've played around with QSOUL a little and considered your ideas. I
> am heavily involved in my own somewhat similar but less orthodox (not
> that yours is orthodox in most senses ;) project, and I thought I'd
> share what I'd developed.
> 
> The source code is at http://www.tunes.org/~water/arrow and most of
> it is not relevant to your average Smalltalker. However, I managed to
> create a really neat little utility that others interesting in
> functional/logic ideas would find possibly useful to look at. (Please
> ignore the project file which contains out-of-date code.)
> 
> I have these lazy (immutable but often infinite) collections with
> caches which can be made either Weak or regular Sets for the various
> purposes these collections play. Because they contain arrows (this is
> the part most irrelevant to Smalltalkers), I call them graphs, but
> otherwise your average Smalltalker should not find them too difficult.
> 
> Anyway, part of the protocol is that I can take lazy collections of
> objects and filter them with a block as a one-item predicate query.
> ArrowGraph class>>top returns basically the top collection type
> instance that contains everything when queried. The filter operator
> is >> and can be sequentially-applied quite safely.
> 
> So basically I can enter:
> 
> f _ ArrowWorld objects.    "Due to the current arrow architecture."
> g _ f >> [:value | value isKindOf: Number].
> g includes: (Arrow wrapping: 3/4 in: f).    "A membership test."
> 
> and g will contain all the numbers. g can accept further filters
> itself. You can force addition of elements to the cache of a filter
> using +. Filtered lazy collections can also be lazily combined with
> set operations | and &. The existential quantification feature
> requires a pattern-matcher which is integral to Arrow so it's not
> likely your average Smalltalker would want to put up with the whole
> Arrow environment overhead to get the benefit (at least until I
> mature the architecture and manage to fork a Smalltalk utility
> sub-package for the matcher).
> 
> Anyway, what do you think?
> ~

--
Roel Wuyts                           Software Composition Group
Roel.Wuyts at iam.unibe.ch         University of Bern, Switzerland
Board member of the European Smalltalk User Group: www.esug.org