Here’s another option!

  def segment_path(path) when is_binary(path) do
    segments = String.split(path, "/", trim: true)

    paths =
      Enum.reduce(segments, [], fn
        segment, [] -> ["/#{segment}"]
        segment, [head | _tail] = whole -> ["#{head}/#{segment}" | whole]
      end)

    Enum.zip(segments, Enum.reverse(paths))
  end
end

What makes this more readable IMHO:

• Fewer LOC
• Contained in one function which tells me a clear story
• Building the paths as we move forward in a visually clear way with interpolation rather than list |> Enum.reverse() |> Enum.join()
• Only reversing one list at the end
• Using Enum.reduce/3 which is very familiar to most Elixir devs

You can of course pipe the reduce block into Enum.reverse() instead of inlining it in the zip call, if that’s your preference

As an added bonus this implementation benchmarks 20% faster on my machine than your original

Another way:

def segment_path(path) do
  path_levels =
    path
    |> String.split("/", trim: true)
    |> length()

  path
  |> breadcrumb()
  |> Stream.iterate(fn
    {segment, segment_path} ->
      parent_path = String.replace_trailing(segment_path, "/#{segment}", "")
      breadcrumb(parent_path)
  end)
  |> Enum.take(path_levels)
  |> Enum.reverse()
end

def breadcrumb(path) do
  segment = path
  |> String.split("/")
  |> List.last()

  {segment, path}
end

The solution with this code unfolds like this:

path = "/some/path/to/nowhere"

1. {"nowhere", "/some/path/to/nowhere"}
2. {"to", "/some/path/to"}
3. {"path", "/some/path"}
4. {"some", "/some"}

Then it’s reversed.

I won’t add reasoning on why (or whether) this is better, but just another implementation.

Hopefully this is at least par for the course . @Ninigi I’m interested in what you’d use instead of do_ here.

defmodule Example do
  def segment_path(path) do
    path |> String.split("/", trim: true) |> do_segment_path("")
  end

  defp do_segment_path([], _path), do: []

  defp do_segment_path([current | rest], path) do
    new_path = "#{path}/#{current}"
    [{current, new_path} | do_segment_path(rest, new_path)]
  end
end

Running:

iex(1)> Example.segment_path("path/to/segment")
[{"path", "/path"}, {"to", "/path/to"}, {"segment", "/path/to/segment"}]

Late to the party here, but I’d use the Path helpers:

  def segment_path(path) when is_binary(path) do
    do_segment_path(path)
    |> Enum.reverse()
  end

  defp do_segment_path("/"), do: []

  defp do_segment_path(path) do
    [ { Path.basename(path), path } | do_segment_path(Path.dirname(path)) ]
  end

Awesome, thank you all for your responses!

Enum.scan.3 is actually what I was looking for, but the name didn’t poke out to me. Looks like I need to just do another read-through of the entire Enum module as it’s been quite a while. Stream.iterate/2 is super interesting and was wholly unaware of it.

@msimonborg I like your points but interestingly or not, I always do my best to find an alternative whenever I find myself needing reduce. It’s not that I think it should never be used, and it certainly is sometimes, but I feel it hurts code “scannability”. Since reduce is the most generalized enumerator you can get, just reading its name alone tells an incredibly generalized story about what is about to happen. This forces me to read through a bit of the implementation, even if I don’t care about it, thus hurting scannability. So I always look for an alternative in Enum that is going that is more tailored to what I want to accomplish. Of course, in this instance, not only did I completely miss scan/3, I chose recursion which is definitely not more “scannable”. While I don’t avoid reduce at all costs, I was definitely trying to do so and took it a little too far this time.

That said, I would say that the scan/3 solution is my favourite here. While I somewhat agree that it is better to use functions that more people are familiar with, I feel like once you come across a function a couple of times and look it up it becomes pretty ingrained. Now that I know about scan, just seeing the name itself will give a lot of information about what’s about to happen, and I prefer optimizing for that.

Anyway, thanks again, all—Glad I asked!