[squeak-dev] Thoughts on Xtreams

Chris Cunnington brasspen at gmail.com
Fri Oct 2 15:06:26 UTC 2015


I'm using the Altitude web framework. It is based on Xtreams. I've tied
myself into knots and now I have had an epiphany about what the problem is.
I don't think I have a working model in my head about what Xtreams is doing
or why. I'm going to say a few things here for other people hopefully to
have a comment on.

My conception of Streams comes from Ch. 10 of "Squeak By Example". This is
a very friendly chapter (Thank you Stephane Ducasse), because the examples
are short, complete and fit into a Workspace.

There are some examples on the Xtreams Google Code page that do fit into a
Workspace, but I don't think they help understanding Xtreams, really. There
is a bigger picture solution that Xtreams addresses. I can see where it's
pointing, I just cannot see how to use it yet.

The problem is I keep wanting to see a whole stream at once, to put it into
a Workspace. Xtreams does not let you see a whole stream coming over a
socket at once. Ever. It's maddening. I want to see what I'm dealing with
and then deal with it. All I see are classes piled on top of each other.

And then I remembered a conversation I had at an event where someone said,"
Xtreams are just like the infinite streams described in 'The Structure And
Interpretation Of Computer Programs', isn't that cool. You can process an
infinite stream."

Yes, I nodded. It sure is cool. I made a mental note to look up streams in
SICP at a future date.

This is that date. And the SICP has some fascinating things to say about
streams.  From section 3.5:

"Stream processing lets us model systems that have state without ever using
assignment or mutable data. This has important implications, both
theoretical and practical, because we can build models that avoid drawbacks
inherent in introducing assignment. On the other hand, the stream framework
raises difficulties of its own, and the question of which modelling
technique leads to more modular and easily maintained systems remains
open."

"Unfortunately, if we represent sequences as lists, this elegance is bought
at the price of sever inefficiency with respect to both time and space
required by our computations. When we represent manipulations on sequences
as transformations of lists, our programs must construct and copy data
structures (which may be huge) at every step of the process."

Our current streams implementation is inefficient because it copies
everything whole, which consumes masses of unnecessary memory. With Xtreams
we can manage an infinitely long stream, saving resources. But it leads to
the problem I've been complaining about which is I cannot see the stream
I'm working on. That is something I'm going to have to adapt to. It sounds
worth the effort. But as the first passage makes clear, it's modelling the
data in a different, dare I say non-object oriented way (functional?).

Why do we want Xtreams? It saves resources and allows us to process
infinitely. In comparison, our Streams classes are crude and inefficient.
What price do we have to pay? We need to mentally conceptualize streams in
a different -- perhaps, extremely different -- way.

I do not have a mental model for what Xtreams is doing yet. How do other
people conceptualize using Xtreams in contrast to the existing Streams
implementation?

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20151002/6c03c3fb/attachment.htm


More information about the Squeak-dev mailing list