Interesting.

Post #7,286 by static 8/30/01 8:42:11 PM Reply	Interesting. My first thought was that they were borrowing from Smalltalk until I read where he got the idea of generators from... Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #7,333 by Fearless Freep 8/31/01 12:50:35 PM Reply	Nope My first thought was that they were borrowing from Smalltalk They didn't, and that's why I'm not happy with them Iterators are implemented by changing the underlying object model slightly and adding some new built in functions and making changes to the effects of certain syntactical elements. In Smalltalk, iterators are just a natural use of the exising object model, based on the same simple and consistant approach Python keeps changing and adding to the core language and syntax, rather then keeping a simple and consistant core and adding functionality by improving class libraries. This has been my frustration with Python, the existing classes are a good start but still need a lot of fleshing out, but all development in the last few releases have been along lines of changing the core library. A good collection library would've made iterators easy to add without requiring syntactical changes. Good iterators would've made list comprehensions unneccessary. Python performance, I think, may drive some of this. By making iterators (or part of the implementation) a builtin function, you can get better performance than you could if you just coded something similar in Python. I think, as a result, when a new desired feature comes along, there is a temptation to implement it as a change to the core language so it can be written in C and thus have acceptable performance, rathert than putting the effort and research into actually improving Python performance and growing the language by extending the Python-written classes But Python totally misses the point and philosophy of Smalltalk iterators Jay O'Connor "Going places unmapped to do things unplanned to people unsuspecting"
Post #7,409 by static 8/31/01 11:32:07 PM Reply	Don't know Python. From your description, Python strikes me as another "let's re-invent the wheel" effort. :-/ Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #7,583 by ben_tilly 9/3/01 7:11:51 PM Reply	What do you think of Ruby's iterators and generators? I am not sure what Smalltalk's are like. But Ruby has had iterators and generators for a long time and they are a basic part of the language. What you do is define a class, give it a method called each which will when called yield each element in turn and then return. Then mixin [link\|http://www.rubycentral.com/book/ref_m_enumerable.html\|Enumerable]. And you are done. You have a class whose objects suport the basic list-oriented access methods. You can loop over it. You can call find, collect, etc. And if you add the <=> method, then you can call methods like max, sort, etc. How well integrated is this into the language? Well yield is basic. A fundamental paradigm throughout the language is transfering control back to the caller with yield. (Ruby actually supports full continuations.) Mixins are basic. They allow many classes to define common methods from a few basic ones. You just write the code once in a module, then include that module in many classes. You can think of them as a controlled form of multiple inheritance. (Ruby has single inheritance.) In point of fact I think that Enumerable is written in C for performance. But if you wanted to write it in Ruby, it would be trivial to do so... Cheers, Ben
Post #7,675 by Fearless Freep 9/4/01 7:01:58 PM Reply	Re: What do you think of Ruby's iterators and generators? I am not sure what Smalltalk's are like. But Ruby has had iterators and generators for a long time and they are a basic part of the language. Smalltalk doesn't even have iterators as such as part of the language. It implements two kinds of iterators using more primitive language parts. Basically, you implement itteration using just objects (especially closures) and message sends. Internal iterators using block closures that loop over the elements ina collection, executing the closure for each element in the collection and doing something with the result. They are called 'internal' because basically you hand the collection a closure and it executes the closure for each element in the collection, sequentially, without interruption An example would be a simple loop 1 to: 10: do: [:i \| Transcript cr; show: i printString] aCollection do: [: each \| each doSomething] External iterators are usually called "streams" and involve building a wrapper around a collection where the wrapper maintains positioning information about it's location in regards to the collection. External iterators can be more powerful and flexible because they allow greater ways to interrupt the flow of control or to skip ahead or grab arbitary pieces of the stream "Ignore the first three and then print the subsequent sums of the rest of the stream in pairs" str = ReadStream on: #(1,2,3,4,5,7,8,9,10) str skipTo: 3 [str atEnd] whileFalse: [ nextTwo := str next: 2 Transript cr; show: (nextTwo first + nextTwo last) printString ] That's a bit trickier with internal iterators However, I really don't care about "Smalltalk versus Python" iterators froma 'which is better' point of view. I'm just disgruntled at the way Python chose to develop iterators as a change to the language rather then building on the existing structure of the language. (Note that the python 'iterators' we're talking about here are not normal loops but are a new addition to add iteration capability to custom built classes ) Jay O'Connor "Going places unmapped to do things unplanned to people unsuspecting"

Welcome to IWETHEY!