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:
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.
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:
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)
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:
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.