Forum: Ruby-core [ruby-trunk - Bug #7691][Open] 3 bugs with Lazy enumerators with state

Posted by marcandre (Marc-Andre Lafortune) (Guest)
on 2013-01-14 06:54
(Received via mailing list)
Issue #7691 has been reported by marcandre (Marc-Andre Lafortune).

----------------------------------------
Bug #7691: 3 bugs with Lazy enumerators with state
https://bugs.ruby-lang.org/issues/7691

Author: marcandre (Marc-Andre Lafortune)
Status: Open
Priority: High
Assignee:
Category: core
Target version: 2.0.0
ruby -v: r38800


I found the following 3 bugs with Lazy#drop, drop_while and zip:

    drop = (1..4).lazy.drop(2)
    drop.to_a # => [3, 4]
    drop.to_a # => [1, 2, 3, 4], should be same as above

    drop_while = (1..4).lazy.drop_while(&:odd?)
    drop_while.to_a # => [2, 3, 4]
    drop_while.to_a # => [1, 2, 3, 4], should be same as above

    zip = (1..2).lazy.zip([3, 4])  # or (3..4)
    zip.to_a # => [[1, 3], [2, 4]]
    zip.to_a # => [[1, nil], [2, nil]] should be same as above

I found them when writing a Ruby implementation of Enumerator::Lazy.

My implementation created the same bug with #take as described in 
https://bugs.ruby-lang.org/issues/6428.

This made me realize that the api of Lazy.new makes it near impossible 
to write most lazy enumerators requiring a state, as there is no general 
way to reset that state.

When looking at my code, I used a state for drop, drop_while and zip. A 
quick verification showed me that the MRI implementation also has the 
same bugs!gene

So the meta question is: should there not be a general way to initialize 
the state of the lazy enum?
Please log in before posting. Registration is free and takes only a minute.
Existing account (Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
No account? Register here.