Rich_Morin

Formatting a list of strings - am I missing anything?

I recently wrote some Elixir to format a list of strings (eg, author names) for output. I think it’s reasonably idiomatic, but I probably missed a few tricks. Suggestions, anyone?

-r

It should work like this…

iex(0)> list_str []    
""
iex(1)> list_str [1]
1
iex(2)> list_str [1,2]
"1 and 2"
iex(3)> list_str [1,2,3] 
"1, 2, and 3"

And now, the code… (ducks)

@doc """
Join a list of strings into a (mostly) comma-delimited string.
"""

def list_str( [] ), do: ""

def list_str( [ one ] ), do: one

def list_str( [ one, two ] ), do: "#{ one } and #{ two }"

def list_str(inp_list) do
  [ last | base_list ]  = Enum.reverse(inp_list)

  base_str  = base_list
  |> Enum.reverse()
  |> Enum.join(", ")

  "#{ base_str }, and #{ last }"
end

18 comments

#functional-programming #pattern-matching #code-style

1 4831 18

2018-12-09 20:42:53 UTC

First 10 of 18 Posts

blatyo

Conduit Core Team

Should probably be:

def list_str( [ one ] ), do: to_string(one)

Otherwise, looks fine to me.

Post #1

Rich_Morin

In case whatever is coming in isn’t already a string. Agreed, but is this any better than (say) “#{ one }”?

Post #2

blatyo

Conduit Core Team

They should be the same. I personally tend to use to_string instead of interpolation, when it’s only the value that I’m converting to a string. I’d use interpolation when I want to convert the values to a string and concatenate with something else.

Post #3

Rich_Morin

That seems to be clearer, in terms of expressing intent, but in this case one could argue for staying in the same style as the following clauses. Dunno…

Post #4

peerreynders

When it comes to serial commas the comma before the “and” is optional - it just can’t be there if you have less than three items.

So I guess recursion isn’t idiomatic?

  def list_str([]),
    do: ""

  def list_str([one]),
    do: to_string(one)

  def list_str(list),
    do: list_str(list, [])

  defp list_str([], [h, n | t]),
    do: list_to_str(t, to_string(n) <> " and " <> to_string(h))

  defp list_str([h | t], rest),
    do: list_str(t, [h | rest])

  defp list_to_str([], str),
    do: str

  defp list_to_str([h | t], str),
    do: list_to_str(t, to_string(h) <> ", " <> str)

Post #5

Rich_Morin

Thank you for that tour de force, Peer. However, it doesn’t produce the requested result, so a picky client might complain and a picky test suite would certainly fail. Do you have a version that would pass?

As I’m sure you realize, omission of the Oxford comma can lead to ambiguity. To cite a well known example, “I’d like to thank my parents, God and Mother Teresa…” So, pedants like me don’t consider it to be optional. (Then again, I also use a lot of optional parentheses and spaces in my code…)

Leaving that issue aside, I wonder about the use of <>. Is this version

to_string(n) <> " and " <> to_string(h)

actually better for some reason (e.g., faster) than this version?

 "#{ n } and #{ h }"

Finally, although your recursive approach is most impressive, does it have any other benefits (aside from its stunning clarity and simplicity) that you can suggest? Inquiring gnomes need to mine…

Post #6

peerreynders

Consistent version

  def list_str([]),
    do: ""

  def list_str([one]),
    do: to_string(one)

  def list_str(list),
    do: list_str(list, [])

  defp list_str([], [h, n]),
    do: list_to_str([], to_string(n) <> " and " <> to_string(h))

  defp list_str([], [h, n | t]),
    do: list_to_str(t, to_string(n) <> ", and " <> to_string(h))

  defp list_str([h | t], rest),
    do: list_str(t, [h | rest])

  defp list_to_str([], str),
    do: str

  defp list_to_str([h | t], str),
    do: list_to_str(t, to_string(h) <> ", " <> str)

Easy version

  def list_str([]),
    do: ""

  def list_str([one]),
    do: to_string(one)

  def list_str([one, two]),
    do: to_string(one) <> " and " <> to_string(two)

  def list_str(list),
    do: list_str(list, [])

  defp list_str([], [h, n | t]),
    do: list_to_str(t, to_string(n) <> ", and " <> to_string(h))

  defp list_str([h | t], rest),
    do: list_str(t, [h | rest])

  defp list_to_str([], str),
    do: str

  defp list_to_str([h | t], str),
    do: list_to_str(t, to_string(h) <> ", " <> str)

actually better for some reason (e.g., faster) than this version?

Haven’t looked at it too deeply - my gut-response is that it likely should be faster but that doesn’t preclude some smarty-pants compile time magic from proving me wrong and even if there is runtime overhead it could be minimal - though I wouldn’t count on it without verification.

Post #7

Rich_Morin

EEx uses “some smarty-pants compile time magic” to turn Phoenix templates into sets of functions; this form of string interpolation doesn’t seem all that different to this newbie…

Post #8