"Richard A. O'Keefe" comments:

> Someone wrote:
>   >No one language does all things well, and it is
>   >true Smalltalk does iteration particularly badly.
>   >But so does Java when you get right down to it.
> 
> I wonder if this is a case of someone not realising that
> the C++ STL "input iterators" and "output iterators" have
> good analogues in Smalltalk: ReadStreams and WriteStreams
> respectively.
> 
> It really boils down to "Smalltalk DOESN'T do iteration, WE do."
> It's an open system.  If there's a better way to iterate than
> the usual collection methods and/or streams, let's find out what
> it is and add it.

I must say that I don't understand this "badness of iteration" in
Smalltalk. What is 'the' iteration?

We've passed through all kind of mapping iterators, folders/reducers
(catamorphisms) etc. in purely functional languages, in APL, in logic
languages, etc., and each set of programming paradigms has its own
"iterator patterns" and style. Whether you call something foldl or
inject:... is not so relevant.

There are imperative constructs, there are also purely functional ones.
It is hard (for me) to believe that a *generic* better way to iterate
exists at all. Backtracking is also a kind of iteration. Difficult to do
in a "classical" language, yet Prolog machines have been constructed in
Smalltalk, as we know.

Of course, Smalltalk has its deficiencies. You can't (apparently) 
define and use an optimized tail-recursive method; if 

anObject doesSomethingWith: params

   ... "folk dance and whatever. At the end, conditionally:"

   ^ self doesSomethingWith: newParams

each call instance will stack the receiver, and finally we get a squeak:
"low memory" or something alike, if the depth is too large. In Scheme (say)

(funct obj params)
 ... ;; which calls at the end
    (funct obj newparams)

will turn in constant space. And that is how the *strict* iteration is defined
in functional languages. The arguments are not stacked, they smash the
previous ones. In principle a good optimizing Smalltalk compiler might do
that as well, although I cannot be categorical. Any opinion of The Gurus?

--

There are also lazy iterators, similar to streams, but permitting to use the
co-recursion to construct and iterate over *infinite* collections of data.

That's why I am waiting for genuine closures in Smalltalk, to check whether
co-recursive algorithms may work... Here no STL pompous patterns can help.

[BTW. VisualWorks docs say that their blocks *are* closures. Anybody tested
that they might be exported out of their method context?]

Jerzy Karczmarczuk
Caen, France