Bug #6142

Enumerable::Lazy#zip doesn't rewind internal enumerators

Added by Innokenty Mikhailov about 2 years ago. Updated over 1 year ago.

[ruby-core:43273]
Status:Closed
Priority:Normal
Assignee:Shugo Maeda
Category:-
Target version:-
ruby -v:ruby 2.0.0dev (2012-03-14 trunk 35013) [x86_64-linux] Backport:

Description

All enumerables passed to Enumerable::Lazy#zip are converted into lazy enumerators.
When result evaluated - ruby iterates over this enumerators while calling #next to retrieve the next value.
But those enumerators are not rewinded:

a = (1..3).lazy.zip('a'..'z')
a.toa #=> [[1, "a"], [2, "b"], [3, "c"]]
a.to
a #=> [[1, "d"], [2, "e"], [3, "f"]]

I believe that is not the desired behavior here and a.to_a should always return the same value.

lazy_zip_to_a.diff Magnifier (1.14 KB) Shugo Maeda, 03/16/2012 12:03 PM

History

#1 Updated by Thomas Sawyer about 2 years ago

A touch OT, but is Brian Candler being involved in the development of this? I don't know of anyone who has discussed and worked on this topic more over the years than Brian and I think it would be most prudent to seek his consul on these matters.

(Not to speak for Brain, of course, but just saying.)

#2 Updated by Shugo Maeda about 2 years ago

Innokenty Mikhailov wrote:

a = (1..3).lazy.zip('a'..'z')
a.toa #=> [[1, "a"], [2, "b"], [3, "c"]]
a.to
a #=> [[1, "d"], [2, "e"], [3, "f"]]

I believe that is not the desired behavior here and a.to_a should always return the same value.

I agree that the current behavior is confusing, and the attached patch fixes it in the above case, but the patch cannot fix it in the following case:

a = (1..3).lazy.zip('a'..'z').map {|i| i.join(":")}
p a.toa #=> ["1:a", "2:b", "3:c"]
p a.to
a #=> ["1:d", "2:e", "3:f"]

It may be difficult to fix it without performance decrease.
We have three options:

(1) Keep the current behavior.
(2) Rewind enumerators only when toa is directly invoked on the lazy enumerator returned by lazy.zip.
(3) Rewind enumerators even if to
a is invoked on a chained enumerator. This may cause performance decrease.

#3 Updated by Shugo Maeda about 2 years ago

Thomas Sawyer wrote:

A touch OT, but is Brian Candler being involved in the development of this? I don't know of anyone who has discussed and worked on this topic more over the years than Brian and I think it would be most prudent to seek his consul on these matters.

Any comments from Brian and others are welcome.
If there is something wrong with the current behavior, please file a ticket or send a mail to ruby-core.

#4 Updated by Shugo Maeda about 2 years ago

  • Status changed from Open to Feedback
  • Assignee set to Shugo Maeda

#5 Updated by Shugo Maeda over 1 year ago

  • Status changed from Feedback to Closed

This issue should be discussed in #7691 and #7696.

Also available in: Atom PDF