YMMV as to where this falls on the golf-vs-readability spectrum, but it’s shorter:

def segment_path(s) do
  s
  |> String.split("/", trim: true)
  |> Enum.scan({nil, ""}, fn el, {_, path} ->
    {el, "#{path}/#{el}"}
  end)
end

The tricky part here is that we only care about part of the “accumulator” for Enum.scan.

Alternatively, you could divide the work into clearer parts:

def segment_path(s) do
  s
  |> String.split("/", trim: true)
  |> Enum.scan([""], &[&1 | &2])
  |> Enum.map(&{hd(&1), Enum.join(Enum.reverse(&1), "/")})
end

The scan here builds a list of lists with (reversed) paths:

[["path"], ["to", "path"], ["segment", "to", "path"]]

Then the map converts those into the desired output shape.

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.

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!

Still a newb so looking for feedback on if this would work:

defmodule ExampleModule do
  @doc """
  Takes a path and returns a list of tuples in the form of:

    [{"segment", "/path/to/segment"}]

  ## Examples:

    iex> ExampleModule.segment_path("/path/to/segment")
    iex> [{"path", "/path"}, {"to", "/path/to"}, {"segment", "/path/to/segment"}]
  """
  @spec segment_path(binary()) :: [{String.t(), String.t()}]
  def segment_path(path) when is_binary(path) do
    path
    |> String.split("/", trim: true)
    |> Enum.scan({nil, ""}, fn
      el, {_, path} when is_binary(path) ->
        {el, "#{path}/#{el}"}
      _, _ ->
        :noop
    end)
    |> Enum.map(fn
      {seg, path} when is_binary(seg) and is_binary(path) ->
        {seg, path |> String.split("/") |> Enum.reverse() |> Enum.join("/")}
      _, _ ->
        :noop
    end)
    |> Enum.reject(&(&1 == :noop))
  end
end

+1 haha. Wonder what your final solution is as a certain lib I am building could use this as extension…

This was for one of my several abandon projects so it never grew. At one point I had my personal site in LiveView until I decide to switch over to Hugo. This is what I landed on but it didn’t have time to grow. It’s based off of @al2o3cr’s first suggestion suggested along with a component. I just build up segments are two-tuples with {segment, path}.

As this is old code I’m not going to look over it to see if I’m embarrassed by it or not as I might not post it

  # In a Utils module

  @doc """
  Taks a path and return a list of tuples in the form of:

    {"segment", "/path/to/segment"}

  ## Example:

    iex> segment_path("/path/to/segment")
    iex> [{"path", "/path"}, {"to", "/path/to"}, {"segement", "/path/to/segment"}]

  This is useful for making breadcrumbs.
  """
  def segment_path(path) when is_binary(path) do
    path
    |> String.split("/", trim: true)
    |> Enum.scan([""], &[&1 | &2])
    |> Enum.map(&{hd(&1), Enum.join(Enum.reverse(&1), "/")})
  end

  # In a components module

  def breadcrumbs(assigns) do
    admin_path = String.replace(assigns.current_path, ~r/\A\/admin/, "")
    breadcrumbs = segment_path(admin_path)
    breadcrumbs = [{"dashboard", ""} | breadcrumbs]

    last = List.last(breadcrumbs)

    assigns = assign(assigns, :breadcrumbs, breadcrumbs)

    ~H"""
    <div class="cursor-default">
      <%= for {name, path} <- @breadcrumbs do %>
        <span class="after:content-['/'] after:text-gray-500 last:after:content-['']">
          <%= if {name, path} == last do %>
            <%= String.capitalize(name) %>
          <% else %>
            <.redirect to={"/admin#{path}"}><%= String.capitalize(name) %></.redirect>
          <% end %>
        </span>
      <% end %>
    </div>
    """
  end

Ok, I did look it over. It’s a little more complex than it needs to be for a show-and-tell but the admin specific stuff is because I was only using them in the admin section. segment_path/1 is the main thing. This was pre-verified routes and one of the reasons I was excited about them.

EDITED: Man, I really didn’t re-read this thread before posting. Sorry for the repeated context.

Just my 2 cents if I was a reviewer:

I’d recommend keeping your original code to segment the path - the new code might be more efficient, but I’d care more about readability than efficiency in code that deals with a string and resulting list of maybe 5 items.

Rename the private functions to something like

defp named_segments...

Otherwise perfectly fine for what it needs to do.

For utility functions like these that do one very simple tiny thing that will very likely never change (and I wish were just in a library), I prefer them to be terse. When they take up a lot of lines it psychologically makes me think they are doing something really important when skimming through code. That’s just me and my personal projects, though. If I wrote that as part of a team and someone wanted me to change it, I wouldn’t protest.

If I wrote this today (this was 9 months ago… I just got pinged on this relatively old thread) I would probably expand the shorthand anonymous functions.

The do_ for private functions that recurse is a very common Elixir idiom which is why I do it. I didn’t like it at first but I really like it now as it acts as general visual “glue” for all recursive functions.

do_ for recursive functions is something the core team has explicitly moved away from, on the base that it’s just lazy naming, and leads to move your core logic into a private function - which is like stuffing your mess into a closet, close the door and call the room “cleaned up”

My opinion on this: if you can’t come up with a name for your recursive function other than do_public_fun, then your logic should probably live in the public function.