RCR enumerable extra into core

ruby-talk
21

Brian Candler wrote:

one logical conclusion (or extreme viewpoint) is that you could always
return an Enumerator, even for

map { |x| x*x }

I wasn't saying that Ruby does anything like this, and it's a tangent to
the original thrust of map(:foo).

That's a pretty yucky option. I use map all the time, and I expect to
get an array back. Adding to_a everywhere is not cool.

Lazy evaluation is cool, though. But it would need a thorough
reconsideration of the language. And considering that Ruby is doing
pretty well without it...

···

--
Gavin Sinclair

22

Hi --

Rick Denatale wrote:

other Enumerators. When you want a real array, then add .to_a to the
end.

And you base this ultimate conclusion on what?

The OP was asking whether map(:foo) should return an Array or an
Enumerator. I was trying to say that if you're ambivalent about this,
one logical conclusion (or extreme viewpoint) is that you could always
return an Enumerator, even for

  map { |x| x*x }

I wasn't saying that Ruby does anything like this, and it's a tangent to
the original thrust of map(:foo).

This reminds me of the early 1.9.0 thing, where you could do:

   array = [1,2,3,4]
   enum = array.enum_for(:map, &lambda {|x| x * x })

   enum.next # 1
   enum.next # 4

etc. (That's ruby 1.9.0 (2008-03-01 revision 15660)
[i686-darwin9.2.0].) To be honest, when that disappeared, it seemed to
me to do away with a great deal of the usefulness of enumerators.
Given that you can no longer attach a block to an enumerator when you
create the enumerator, I don't think there are any actual use cases
for the fact that map returns an enumerator (or at least very, very
few). You can't do this, for example (following the above example):

   enum.select {|x| x > 1 } # [4, 9, 16]

David

···

On Wed, 11 Nov 2009, Brian Candler wrote:

On Tue, Nov 10, 2009 at 10:47 AM, Brian Candler <b.candler@pobox.com> >> wrote:

--
The Ruby training with D. Black, G. Brown, J.McAnally
Compleat Jan 22-23, 2010, Tampa, FL
Rubyist http://www.thecompleatrubyist.com

David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com)

23

Hi,

I'm quite conservative or maybe 'wise', seeing this discussion.

In fact, using arr.map(:method, arg1 ... ) is too confusing to me
While the &:method notation is clear, and not that ugly.

And I think it has to be a separation between blocks and arguments; block is
another "kind" of argument.
That's why I think we should keep the &:method, and forget about :method.
Note also that is not a common use of &:method, because you often need to do
ore than one thing with the element. eg:
[1,15,3].map { |e| e.to_s.length }

P.S.:
Why &:method is faster ? (Bad, I wanted to argue &:method is slower but I
can't ...)
(requiring and including Benchmark)
irb(main):008:0> realtime { (1..1000000).to_a.map &:to_s }
=> 0.38111090660095215
irb(main):009:0> realtime { (1..1000000).to_a.map { |e| e.to_s } }
=> 0.445728063583374

···

2009/11/11 David A. Black <dblack@rubypal.com>

Hi --

On Wed, 11 Nov 2009, Brian Candler wrote:

Rick Denatale wrote:

On Tue, Nov 10, 2009 at 10:47 AM, Brian Candler <b.candler@pobox.com> >>> wrote:

other Enumerators. When you want a real array, then add .to_a to the
end.

And you base this ultimate conclusion on what?

The OP was asking whether map(:foo) should return an Array or an
Enumerator. I was trying to say that if you're ambivalent about this,
one logical conclusion (or extreme viewpoint) is that you could always
return an Enumerator, even for

map { |x| x*x }

I wasn't saying that Ruby does anything like this, and it's a tangent to
the original thrust of map(:foo).

This reminds me of the early 1.9.0 thing, where you could do:

array = [1,2,3,4]
enum = array.enum_for(:map, &lambda {|x| x * x })

enum.next # 1
enum.next # 4

etc. (That's ruby 1.9.0 (2008-03-01 revision 15660)
[i686-darwin9.2.0].) To be honest, when that disappeared, it seemed to
me to do away with a great deal of the usefulness of enumerators.
Given that you can no longer attach a block to an enumerator when you
create the enumerator, I don't think there are any actual use cases
for the fact that map returns an enumerator (or at least very, very
few). You can't do this, for example (following the above example):

enum.select {|x| x > 1 } # [4, 9, 16]

David

--
The Ruby training with D. Black, G. Brown, J.McAnally
Compleat Jan 22-23, 2010, Tampa, FL
Rubyist http://www.thecompleatrubyist.com

David A. Black/Ruby Power and Light, LLC (http://www.rubypal.com)

24

This reminds me of the early 1.9.0 thing, where you could do:

   array = [1,2,3,4]
   enum = array.enum_for(:map, &lambda {|x| x * x })

   enum.next # 1
   enum.next # 4

It is surprising that currently it appears to *ignore* the given block.

b = File.open('file', 'r').lines{|line| lines * 2}
b.next

=> "xx\n"

b.next

=> "xx\n"

Is this expected?
-r

···

--
Posted via http://www.ruby-forum.com/\.

25

This reminds me of the early 1.9.0 thing, where you could do:

   array = [1,2,3,4]
   enum = array.enum_for(:map, &lambda {|x| x * x })

   enum.next # 1
   enum.next # 4

Appears somewhat possible...

class Enumerator
  def filter(&blk)
    self.class.new do |y|
      each do |*input|
        out = blk.call(*input)
        y << out
        # or y << out if out
      end
    end
  end
end

array = [1,2,3,4]
enum = array.enum_for(:map).filter {|x| x * x }
enum.next

=> 1

enum.next

=> 4

enum.select {|x| x > 1 } # [4, 9, 16]

=> [4, 9, 16]

[Thanks to Brian Candler for the snippet--though perhaps it could be
improved...]

This should be the default, though--I don't know why blocks are ignored
currently...

-r

http://www.ruby-forum.com/topic/169844#new

···

--
Posted via http://www.ruby-forum.com/\.