Asp Forum - Re: internal iterators in ruby

Geert Fannes

6/3/2005 10:07:00 AM

So, if I understand well, the problem with iterating over different
enumerables synchronously has to do with the absence of a #rewind and
#next method for enumerables. The Generator class solves this using the
slow #callcc method and allows one to step through the Enumerable#each
method, element by element. Wouldn't it be better if the enumerable
required a #rewind and #next method and constructs the #each method out
of these instead of doing the reverse using #callcc?
Greetings,
Geert Fannes.

You code works only for arrays, but it's quite efficient.

This works for all Enumerable types, is less efficient - and it's part
of
the std lib:

http://www.ruby-doc.org/stdlib/libdoc/generator/rdoc/classes/S...
tor.html

Know your standard libs... :-)

Kind regards

robert

7 Answers

Robert Klemme

6/3/2005 10:12:00 AM

Charles Hixson

6/4/2005 8:10:00 PM

Geert Fannes wrote:

>So, if I understand well, the problem with iterating over different
>enumerables synchronously has to do with the absence of a #rewind and
>#next method for enumerables. The Generator class solves this using the
>slow #callcc method and allows one to step through the Enumerable#each
>method, element by element. Wouldn't it be better if the enumerable
>required a #rewind and #next method and constructs the #each method out
>of these instead of doing the reverse using #callcc?
>Greetings,
>Geert Fannes.
>
>
>You code works only for arrays, but it's quite efficient.
>
>This works for all Enumerable types, is less efficient - and it's part
>of
>the std lib:
>
>http://www.ruby-doc.org/stdlib/libdoc/generator/rdoc/classes/S...
>tor.html
>
>Know your standard libs... :-)
>
>Kind regards
>
> robert
>
>
This is one of the reasons that I feel that mixins should be
inheritable. What you really want to do is define a descendant of
Enumerable that implements those methods.

I suppose that what one could do is define a new mixin, say
"TwoWayEnumerable" that implements the standard ops of a doubly linked
list (getting most of them by requiring Enumerable) and use that. Since
it would include the definition of Enumerable, it could be used whenever
Enumerable was needed, but it could also be used in other instances,
such as the one that you are proposing.

But I still feel that inheriting from SuperModules would be nicer
syntactically.

ES

6/4/2005 8:22:00 PM

Le 4/6/2005, "Charles Hixson" <charleshixsn@earthlink.net> a écrit:
>Geert Fannes wrote:
>
>>So, if I understand well, the problem with iterating over different
>>enumerables synchronously has to do with the absence of a #rewind and
>>#next method for enumerables. The Generator class solves this using the
>>slow #callcc method and allows one to step through the Enumerable#each
>>method, element by element. Wouldn't it be better if the enumerable
>>required a #rewind and #next method and constructs the #each method out
>>of these instead of doing the reverse using #callcc?
>>Greetings,
>>Geert Fannes.
>>
>>
>>You code works only for arrays, but it's quite efficient.
>>
>>This works for all Enumerable types, is less efficient - and it's part
>>of
>>the std lib:
>>
>>http://www.ruby-doc.org/stdlib/libdoc/generator/rdoc/classes/S...
>>tor.html
>>
>>Know your standard libs... :-)
>>
>>Kind regards
>>
>> robert
>>
>>
>This is one of the reasons that I feel that mixins should be
>inheritable. What you really want to do is define a descendant of
>Enumerable that implements those methods.

You can always #include the module in your module. Or, if you
want to get fancy and it happens to suit your purposes, you
can have your module #extend another module.

>I suppose that what one could do is define a new mixin, say
>"TwoWayEnumerable" that implements the standard ops of a doubly linked
>list (getting most of them by requiring Enumerable) and use that. Since
>it would include the definition of Enumerable, it could be used whenever
>Enumerable was needed, but it could also be used in other instances,
>such as the one that you are proposing.
>
>But I still feel that inheriting from SuperModules would be nicer
>syntactically.

E

--
template<typename duck>
void quack(duck& d) { d.quack(); }

Ara.T.Howard

6/4/2005 9:37:00 PM

Charles Hixson

6/5/2005 12:37:00 AM

Ara.T.Howard wrote:

> On Sun, 5 Jun 2005, Charles Hixson wrote:
>
>> Geert Fannes wrote:
>>
>>> So, if I understand well, the problem with iterating over different
>>> enumerables synchronously has to do with the absence of a #rewind and
>>> #next method for enumerables. The Generator class solves this using the
>>> slow #callcc method and allows one to step through the Enumerable#each
>>> method, element by element. Wouldn't it be better if the enumerable
>>> required a #rewind and #next method and constructs the #each method out
>>> of these instead of doing the reverse using #callcc?
>>> Greetings,
>>> Geert Fannes.
>>>
>>>
>>> You code works only for arrays, but it's quite efficient.
>>>
>>> This works for all Enumerable types, is less efficient - and it's part
>>> of
>>> the std lib:
>>>
>>> http://www.ruby-doc.org/stdlib/libdoc/generator/rdoc/classes/S...
>>>
>>> tor.html
>>>
>>> Know your standard libs... :-)
>>>
>>> Kind regards
>>>
>>> robert
>>>
>> This is one of the reasons that I feel that mixins should be
>> inheritable. What you really want to do is define a descendant of
>> Enumerable that implements those methods.
>>
>> I suppose that what one could do is define a new mixin, say
>> "TwoWayEnumerable" that implements the standard ops of a doubly
>> linked list (getting most of them by requiring Enumerable) and use
>> that. Since it would include the definition of Enumerable, it could
>> be used whenever Enumerable was needed, but it could also be used in
>> other instances, such as the one that you are proposing.
>>
>> But I still feel that inheriting from SuperModules would be nicer
>> syntactically.
>
>
> this limits you to sharing the functionality of exactly one mixin. the
> current implementation allows sharing of code from many mixins.
>
> class TwoWayEnumerable
> include Enumerable
> include SomeMoreNiftyMethods
> include EvenMoreFunctionality
> end
>
> ruby's single inheritence would preclude this as a possibility - at
> least it
> would be precluded from doing in a nice way syntactically.
>
> cheers.
>
> -a

You are correct, if I had been thinking of TwoWayEnumerable as a class.
What I was wishing was to use the same inheritance semantics on
Modules. Since no class would be involved, there wouldn't be any
restriction to "single inheritance". (Actually, I'd prefer multiple
inheritance ala Eiffel or Python, but I understood when I came to Ruby
that this was one feature I was abandoning.)

OTOH, I realize that this would just be equivalent to:
module TwoWayEnumerable
include Enumerable
include TwoWayList
...
end # TwoWayEnumerable

But I would prefer the look of:
module TwoWayEnumerable < Enumerable, TwoWayList
...
end # TwoWayEnumerable

That said, I realize that this is a truly minor point, and only a matter
of taste.
(Also that the include method would need to be maintained, because
sometimes on wants inclusion to be the result of a test, or to occur
after a certain point in the class.)

Martin DeMello

6/5/2005 6:39:00 AM

Geert Fannes <Geert.Fannes@ikanconsulting.com> wrote:
> So, if I understand well, the problem with iterating over different
> enumerables synchronously has to do with the absence of a #rewind and
> #next method for enumerables. The Generator class solves this using the
> slow #callcc method and allows one to step through the Enumerable#each
> method, element by element. Wouldn't it be better if the enumerable
> required a #rewind and #next method and constructs the #each method out
> of these instead of doing the reverse using #callcc?

Note that an internal iterator is a (capable of being atomic) method,
whereas an external iterator is an *object* holding the state of the
iterator. If you want to implement #next, you need somewhere to store
@current, and the object you're iterating over is not that place.

martin

corella

6/22/2009 2:39:00 AM

On Jun 22, 12:24 pm, corella <cocka...@aussieisp.net.au> wrote:
> > It's all there in the text. The protective hand of America is being
> > subverted by Russia China and India as a group who intend to take
> > over...under a 'fairness' doctrine. The trouble is, none of those
> > countries have legal systems that have ever guaranteed freedoms to people.
> > Hence the warning about * language* used to convey something that you won't
> > get in reality.
> > I thought it was pretty clear.
>
> http://www.andrew-roberts.net/pages/books/history_of_englis......
>
> You'd find a kindred spirit in this militarist empireist
> Thatcherite's book.

The legal system guaranteeing freedoms. What a joke!

The legal system guarantees repression and criminalization; whilst
providing a vocation
for unproductive authoritative suppressive characters funded through
the taxpayer.

comp.lang.ruby

Re: internal iterators in ruby

Geert Fannes

Robert Klemme

Charles Hixson

ES

Ara.T.Howard

Charles Hixson

Martin DeMello

corella

x Login to ForumsZone