If I were to really use this in production, I’d likely wrap it in its own struct module like this:

defmodule WeightedList do
  defstruct [:acc_list, :max]

  def new(kw_list) do
  # Might want to verify it is sorted lowest to highest weight
  acc_list = Enum.scan(kw_list, fn {k, w}, {_, w_sum} -> {k, w + w_sum} end)
  {_, max} = List.last(acc_list)
  %__MODULE__{acc_list: acc_list, max: max}
  end

  def sample(%__MODULE__{acc_list: acc_list, max: max}) do
    rand_value = Enum.random(1..max)
    Enum.find_value(acc_list, fn
      {k, w} when rand_value <= w -> k
      _ -> false
    end)
  end
end

Which could then be used in calling code like

wl = WeightedList.new(apples: 10, oranges: 30, bananas: 60)
# now let's get 10 random samples
samples = for _ <- 1..10, do: WeightedList.sample(wl)

This represents a pattern I’ve found myself favoring lately. Create an optimized data structure for the sorts of functions you will want to use on it. The calling code then has a 2 step process: 1) create the struct, 2) call the function. This may seem unnecessary, but you can unit test step 1 easily since there are no side effects (or randomness).

Plus, having a struct allows you to participate in Protocols. I could imagine WeightedList implementing Inspect and perhaps even Collectable if it’s an important enough part of your system.

Edited to use Enum.find_value instead of Enum.reduce_while which I find clearer for this situation

Thank you so much everyone! This is way more than I expected. It’s a lot to digest, I’ve learned so much. I like @gregvaughn’s suggestion the most, not because of the struct idea, but because it seems to me to realise the thought process in my original approach, except without all the noobish bloat. The struct idea is also fascinating as well of course.

A quick question about differentiating functions by arity, like this:

This of course seems to be quite idiomatic, but I’m struggling with reaching for it myself. I just feel that if a function does something different it should have a different name. Perhaps naively I think it’s better to make the condition explicit in say a case statement, and then call out to differently named functions just so that the intent of the code becomes more intuitive. Thoughts?

As @LostKobrakai already pointed out, both do the same thing. They select the item from the list of items.

The multiheaded function you see there, has nothing to do with “differentiating functions by arity”, in fact, nothing is differentiated there, both are the same function, as both have the same name and the same arity.

What though I do use there is “pattern matching”, something very important to learn and understand when writing elixir.

To be honest, those 2 function clauses are semantically equivalent with the following single-clause function:

defp select_item(items, idx) do
  case items do
    [{name, weight}|_] when idx < weight -> name
    [{_, weight} | tail] -> select_item(tail, idx - weight)
  end
end

But it is idiomatic to move such a case which matches on an argument directly and spans the full function body into a multi clause function.

Also in general pattern matching in the functions head or a case is usually prefered of using if and some predicate functions and/or using getter functions.

Pattern matching‡ is the conditional construct - the case expression is just one way of utilizing it.

‡ Not to be confused with destructuring:

• Kernel.destructure/2
• JavaScript destructuring assignment

Can’t we write select_item/3 roughly like this, making it effectively a select_item/2?

defp select_item([{name, weight} | _], idx) when idx < weight, do: name
defp select_item([{_, weight} | tail], idx), do: select_item(tail, idx - weight)

While also making use of Enum.reduce/3 in sum_weights/2 we can make it a sum_weights/1:

defp sum_weights(items) do
  Enum.reduce(items, 0, fn {_, weight}, sum -> weight + sum end)
end

Then we leave weight_based_choice nearly untouched (only adjusting calls to the functions we changed):

defmodule Demo do
  def weight_based_choice(items) do
    value =
      items
      |> sum_weights()
      |> :rand.uniform()

    select_item(items, value)
  end

  defp select_item([{name, weight} | _], idx) when idx < weight, do: name
  defp select_item([{_, weight} | tail], idx), do: select_item(tail, idx - weight)

  defp sum_weights(items) do
    Enum.reduce(items, 0, fn {_, weight}, sum -> weight + sum end)
  end
end

 1..10 |> Enum.map(fn _ -> Demo.weight_based_choice(items) end) |> IO.inspect
#=> [:bananas, :bananas, :bananas, :bananas, :bananas, :bananas, :bananas, :bananas, :oranges, :bananas]

This is probably one of the most idiomatic approaches. We could even implement select_item/2 in terms of Enum.reduce_while/3, but usually this doesn’t add much in terms of readability, also not many people are used to that function…

defp select_item(items, idx) do
  Enum.reduce_while(items, idx, fn
    {_, weight}, acc when weight < acc -> {:cont, acc - weight}
    {name, weight}, acc -> {:halt, name}
  end
end

PS: Perhaps we need to adjust </<=/>/>= in the guards… I’m writing this mostly freehand…