Issue #6158 has been updated by Shugo Maeda.

Status changed from Open to Assigned
Assignee set to Shugo Maeda

Hello,

Benoit Daloze wrote:
> I noticed #take is now defined on Enumerator::Lazy, and it has lazy behavior:
> 
>     (1..1000).lazy.select(&:even?).take 3 # => #<Enumerator::Lazy ...>
> 
> I would expect #take to not be lazy and always produce an Array, like the original Enumerable#take does.
> I think many rubyists would expect that too.
> 
> Do you have a use case for a lazy #take ? I can't find one right now.

At first, I had the same opinion, but lazy take is sometimes useful.
For example, the following code consume much memory if take is not lazy.

  sum = e.lazy.take(1000000).inject(:+)

Scheme's stream-take, which is equivalent to Enumerator::Lazy#take, is also lazy.
 
gosh> (use util.stream)
#<undef>
gosh> (stream-take (stream-iota -1 3 2) 3)
#<promise(stream) 0x9e4fc80>
gosh> (stream->list (stream-take (stream-iota -1 3 2) 3))
(3 5 7)

> I've seen #6152, although I can't read it.
> I think `lazy.take(5)` should be equal to `lazy.first(5)` and it reads better.

I think it's good to have both the eager and lazy version of take.

----------------------------------------
Bug #6158: Enumerator::Lazy#take: should it be lazy?
https://bugs.ruby-lang.org/issues/6158#change-24651

Author: Benoit Daloze
Status: Assigned
Priority: Normal
Assignee: Shugo Maeda
Category: 
Target version: 
ruby -v: ruby 2.0.0dev (2012-03-15 trunk 35042) [x86_64-darwin10.8.0]


Hello,

I noticed #take is now defined on Enumerator::Lazy, and it has lazy behavior:

    (1..1000).lazy.select(&:even?).take 3 # => #<Enumerator::Lazy ...>

I would expect #take to not be lazy and always produce an Array, like the original Enumerable#take does.
I think many rubyists would expect that too.

Do you have a use case for a lazy #take ? I can't find one right now.

I've seen #6152, although I can't read it.
I think `lazy.take(5)` should be equal to `lazy.first(5)` and it reads better.


-- 
http://bugs.ruby-lang.org/