Enum.reduce/2 throws Enum.EmptyError

Enum.reduce/3 works because it will just return the accumulator in the second argument. With Enum.reduce/2 the first element in the enumerable is used as the initial accumulator but if the enumerable is empty then what should be returned.

We can’t return [] because that does not make sense in many applications, for example if you want to sum a list:

Enum.reduce([1, 2, 3, 4], fn(x, acc) -> x * acc end) #=> 10
Enum.reduce([], fn(x, acc) -> x * acc end) #=> [] / 0 ???

Why do you specifically need Enum.reduce/2?

I needed to find a special value among a list.

The way it works is to consider the first element as winner, and then compare last winner with next element. At last, there will be winner inside accumulator.

This works like a basic algorithm of finding minimum/maximum inside a list.

I couldn’t find other functions that can iterate over a list, with an accumulator. There is only Enum.reduce/2 and Enum.reduce/3 (I think?).

I solved the problem by pattern matching empty list on my function, and returning the desired empty value.

But I’m curious to know what other options do I have? Using Enum.reduce/3 is not elegant:

first_element_or_nil_value = case a_list do
  [first | _tail] -> first
  _others -> some_nil_value
end
Enum.reduce(a_list, first_element_or_nil_value, iterator)

Where I should define first_element_or_nil_value in some other place.

And one more thing: I think this case should be mentioned in documentations, don’t you?

Pattern matching is probably the best solution, you have to decide somewhere in your application what to do if you cant select a winner because there are no elements to select from. You can also do this:

{first, tail} = Enum.split(list, 1)
Enum.reduce(tail, List.first(first), fn ...)

I agree, we seem to have it for other functions, please open an issue or send a pull request.

My choice would have been:

defmodule Demo do
  def run(a_list, default_value) do
    iterator = fn
      x, ^default_value -> x
      x, win when win < x -> x
      _, win -> win
    end
    Enum.reduce(a_list, default_value, iterator)
  end
end

IO.inspect (Demo.run [], :no_winner)
IO.inspect (Demo.run [1,2,3], :no_winner)
IO.inspect (Demo.run [3,1,2], :no_winner)

$ elixir demo.exs
:no_winner
3
3

Of course intercepting the empty case before it gets to the reduce is more “efficient” (though by all accounts pattern matching is pretty fast) and ultimately creates the scenario that reduce/2 was designed for - i.e. it already has been established that the enumerable has at least one item (which doesn’t need to be evaluated by the function).

defmodule Demo2 do
  def reduce([h|t],f) do
    Enum.reduce(t,h,f)
  end
end

fun = fn (x, acc) -> x * 2 + acc end
IO.inspect (Enum.reduce [3,2,1],0,fun)
IO.inspect (Demo2.reduce [3,2,1],fun)
IO.inspect (Enum.reduce [3,2,1],fun)

$ elixir demo2.exs
12
9
9

Thanks, but my condition could not be expressed through a simple when. It required some computation and is currently a 5-line-pipe.

Currently, pattern matching an empty list and returning a default value is a good and elegant solution.

If it were simpler, I would use Enum.min_by/3 or Enum.max_by/3, which are designed to do this.

That wasn’t the point. Your statement was that a solution involving Enum.reduce/3 would be inelegant because you elected to use some conditional logic to select an appropriate initial value. I merely pointed out that it is possible with a multi clause anonymous function to simply swap out the supplied default value if and when the first element is processed.

I think that you have found the solution that works best for your particular situation.

That being said I find that Enum.reduce/2 isn’t as generally useful as the Enum.reduce/3 form - conceptually Enum.reduce/2 is simply a specialized case:

def reduce([h|t],f) do
  Enum.reduce(t,h,f)
end

of Enum.reduce/3 which results in the following limitations:

• The list has to have at least one item (as you have found out for yourself) as the presence of a “head” is required.
• The head of the list is (potentially) never processed in the same fashion by the supplied function as all the subsequent elements are - as it is simply treated as an initial value.

So even with your solution I’d still be tempted to use Enum.reduce/3 over Enum.reduce/2 in the following fashion:

  def run([]),
    do: :no_winner
  def run([x|xs]),
    do: (Enum.reduce xs, x, &iteratee/2)

simply because it is much clearer that the head of the list is being treated as an initial value and therefore may be processed differently to the remaining elements (depending on the logic in iteratee). When “reducing” Enum.reduce/3 should be the “goto”. When you know that you are dealing with a list you can use the equivalent List.foldl/3 or List.foldr/3 which processes the elements in the opposite order.

There is no harm in forgetting that Enum.reduce/2 even exists - it’s a “convenience” form that isn’t all that convenient.