[#51213] [ruby-trunk - Bug #7645][Open] BigDecimal#== slow when compared to true/false — "mathie (Graeme Mathieson)" <mathie@...>

11 messages 2013/01/01

[#51328] [ruby-trunk - Bug #7676][Open] Comparison of Float::NAN in array behaves unexpectedly — "simonrussell (Simon Russell)" <spam+ruby@...>

11 messages 2013/01/09

[#51347] [ruby-trunk - Bug #7679][Open] IRB history is broken — "zzak (Zachary Scott)" <zachary@...>

15 messages 2013/01/10

[#51389] [ruby-trunk - Bug #7688][Open] Error hiding with rb_rescue() on Comparable#==, #coerce and others — "Eregon (Benoit Daloze)" <redmine@...>

34 messages 2013/01/11

[#51430] [ruby-trunk - Bug #7696][Open] Lazy enumerators with state can't be rewound — "marcandre (Marc-Andre Lafortune)" <ruby-core@...>

15 messages 2013/01/14

[#51437] [ruby-trunk - Bug #7698][Open] RubyGems 2.0 has an incompatibility about installation of extension libraries — "mrkn (Kenta Murata)" <muraken@...>

21 messages 2013/01/15

[#51454] [CommonRuby - Feature #7701][Open] Non-optional (required) keyword args — "headius (Charles Nutter)" <headius@...>

31 messages 2013/01/15

[#51499] [ruby-trunk - Feature #7712][Open] Add .txt extensions to all plain-text documentation files for Windows users — "postmodern (Hal Brodigan)" <postmodern.mod3@...>

9 messages 2013/01/18

[#51619] [ruby-trunk - Feature #7738][Open] Deprecate Set#+ as an alias of Set#|, use it for symmetric difference. Introduce Hash#| for Hash#reverse_merge in Rails. — "alexeymuranov (Alexey Muranov)" <redmine@...>

11 messages 2013/01/24

[#51623] [ruby-trunk - Feature #7739][Open] Define Hash#| as Hash#reverse_merge in Rails — "alexeymuranov (Alexey Muranov)" <redmine@...>

24 messages 2013/01/24

[#51714] [CommonRuby - Feature #7747][Open] Expanded API for Binding semantics — "jballanc (Joshua Ballanco)" <jballanc@...>

19 messages 2013/01/27

[#51742] [ruby-trunk - Bug #7756][Open] clang 3.2 sees through UNINITIALIZED_VAR macro, gives warning — "drbrain (Eric Hodel)" <drbrain@...7.net>

10 messages 2013/01/29

[#51763] [ruby-trunk - Bug #7758][Open] Ruby on Windows crashes when active codepage is codepage 65001 and outputting unicode character — "joshc (Josh C)" <josh.nw@...>

16 messages 2013/01/30

[ruby-core:51410] [ruby-trunk - Bug #7690][Assigned] Enumerable::Lazy#flat_map should not call each

From: "shugo (Shugo Maeda)" <redmine@...>
Date: 2013-01-13 23:48:43 UTC
List: ruby-core #51410
Issue #7690 has been updated by shugo (Shugo Maeda).

Status changed from Open to Assigned
Assignee set to shugo (Shugo Maeda)

marcandre (Marc-Andre Lafortune) wrote:
> I would expect that
> 
>     array.flat_map{...} == array.lazy.flat_map{...}.force
> 
> This is not always the case:
> 
>     [1].flat_map{|i| {i => i} } # => [{1 => 1}], ok
>     [1].lazy.flat_map{|i| {i => i} }.force # => [[1, 1]], expected [{1 => 1}]

I agree that this looks weird.

> Note that Matz confirmed that it is acceptable to return straight objects instead of arrays for flat_map [ruby-core:43365]
> 
> It looks like this was intended for nested lazy enumerators:
> 
>     [1].lazy.flat_map{|i| [i].lazy }.force # => [1]
> 
> I don't think that's the correct result, and it is different from a straight flat_map:
> 
>     [1].flat_map{|i| [i].lazy } # => [#<Enumerator::Lazy: [1]>]

[1].lazy.flat_map{|i| [i].lazy } should flatten nested lazy enumerators, because Enumerable::Lazy is a monad and flat_map is the monad's bind operator.
In the monad, [x].lazy is equivalent to Haskell's return and flat_map is equivalent to Haskell's >>= (bind).

  # return :: a -> ma
  [x].lazy

  # (>>=)  :: m a -> (a -> m b) -> m b
  x.flat_map(&f)

Note that f's type is a -> m b, which means that f returns not an Array, but an Enumerable::Lazy.

In fact, [x].lazy and flat_map obey the monad laws.

  # (return x) >>= f == f x
  [x].lazy.flat_map(&f) == f.(x)

  # m >>= return == m
  m.flat_map { |i| [i].lazy } == m 

  # (m >>= f) >>= g == m >>= (\x -> f x >>= g)
  m.flat_map(&f).flat_map(&g) == m.flat_map { |x| f.(x).flat_map(&g) }

That is, flat_map is an operator to compose computations which return an Enumerable::Lazy.

Do you have any use case of [1].flat_map{|i| {i => i} }?

----------------------------------------
Bug #7690: Enumerable::Lazy#flat_map should not call each
https://bugs.ruby-lang.org/issues/7690#change-35388

Author: marcandre (Marc-Andre Lafortune)
Status: Assigned
Priority: Normal
Assignee: shugo (Shugo Maeda)
Category: core
Target version: 2.0.0
ruby -v: r38794


I would expect that

    array.flat_map{...} == array.lazy.flat_map{...}.force

This is not always the case:

    [1].flat_map{|i| {i => i} } # => [{1 => 1}], ok
    [1].lazy.flat_map{|i| {i => i} }.force # => [[1, 1]], expected [{1 => 1}]

Note that Matz confirmed that it is acceptable to return straight objects instead of arrays for flat_map [ruby-core:43365]

It looks like this was intended for nested lazy enumerators:

    [1].lazy.flat_map{|i| [i].lazy }.force # => [1]

I don't think that's the correct result, and it is different from a straight flat_map:

    [1].flat_map{|i| [i].lazy } # => [#<Enumerator::Lazy: [1]>]

This is caused by Lazy#flat_map calls each (while Enumerable#flat_map only looks for Arrays/object responding to to_ary).





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

In This Thread