Marcel Weiher wrote:
> 
> > > that to fully understand Smalltalk and its power, you will have to
> > > jettison that analogy at some point.
> >
> > I disagree here. I have a thorough understanding of OO in general,
> > and how Smalltalk implements it; and in general, OO does use normal
> > subroutine calls (but the subroutine actually executed is selected
> > at run-time, based on the object's class).
> 
> Again, Smalltalk messaging can and does do more than that, because
> it is less specific.  For example, I don't see multicast and
> broadcast as fitting in the conceptual framework of subroutines,  but
> they're fine for messages, just like forwarding/delegation.

Well, I'm talking and thinking about Smalltalk-80. I'm not aware of
anything that one could call broadcast or multicast there (but I admit I
may have overlooked it - my understanding of Smalltalk goes back to the
colored books, and the language may have changed since then despite
surface appearance).

> > However, my understanding of subroutines is more general than many
> > seem to think here. In my eyes, a subroutine is characterized by its
> > effect, not by the sequence of actions that it contains.
> 
> Hmm, I think subroutine is a very specific concept, distinct from,
> say, coroutine.  If your understanding of subroutine includes a
> coroutine, you might want to use a different term.

Well, a coroutine has some similarities, but it's purpose is quite
different, so I consider them different.

> I am not quite sure if we're using the same definition of
> 'subroutine' and 'multiple return values' here.
> 
> What I am talking about with multiple return values is multiple
> values, each 'returned' (sent-back) individually at different times,
> not tuples of return values.

Ah, now I understand.
And I don't think it's a good idea (it introduces lots of state that can
get out of sync with outside expectations), but that's just generally
speaking; good language design may be able to harness such problems.

> For example, an iterator that 'returns' the elements of its
> collection:
> 
> contents
>         self do:[ :each | ^^each ].                     " ^^ stands
> for 'return but continue executing' "

Conceptually, such things are more clearly implemented via lazy
evaluation: expressions are not evaluated until their result is
required. This does not introduce additional state into the system, and
it gives you the power to express such things.
Here's how: Write a function that returns an infinite sequence (this is
easy to do via recursion; a loop won't do here). Write an at: selector
that retrieves values from the such a sequence. Calling
myInfiniteSequence at: 3 will evaluate myInfiniteSequence just enough
that at: finds the value that it has to return.
This is a rather systematic way of doing streaming BTW.

There's a caveat here: I lied a bit when I said this does not introduce
additional state. The expressions may go into a Heisenberg state if you
start modifying variables that go into an expression. You're better off
if you make as much stuff constant as you can if you want to use this
style of evaluation.

Another caveat: I'm not sure how much work applying these ideas to
Smalltalk is. I suspect Smalltalk is not built for accommodating them.

Just to give some food for thought. I hope it is of use to you all.

Regards,
Joachim
-- 
Please don't send unsolicited ads.