Newcomer to Elixir, is this idiomatic code? (advent of code solution)

orestis

So I’ve started learning Elixir. I took on the Advent of Code challenges, and solved the first day. I’ve skimmed a few books on elixir/erlang, and have had some exposure to FP constructs (including a pleasant semester of Prolog at uni 10 years ago ).

I came up with the following solution to the day 1 problem. The two test functions showcase what the requirements are (and hopefully the implementation is written such a way what it will be immediately obvious).

Now, after I solved this I searched online to see what other people did. Here are some linked examples:

Reddit Thread
Github 1
Github 2

In those links I see the obvious Enum.reduce approach plus some approaches that seem really weird. I took a classic recursive approach with pattern matching, but only because it’s the feature I prominently remember and I didn’t remember how to write the case construct, so I wanted to see if it would be possible. I have to confess when this code worked, I giggled a bit

So my question is, is this code considered idiomatic Elixir? The Pythonista in me really likes this code, even if it is a bit more verbose than other solutions. Could I rewrite it to be more idiomatic but keeping the same recursive approach?

Thanks!

defmodule Day1 do
  def santa(s) do
    l = String.codepoints(s)
    santa(l, 0)
  end

  defp santa([], n) do
    n
  end

  defp santa(["(" | tail], n) do
    santa(tail, n + 1)
  end

  defp santa([")" | tail], n) do
    santa(tail, n - 1)
  end

  def test_santa do 
    IO.puts(santa("(())") == 0)
    IO.puts(santa("()()") == 0)
    IO.puts(santa("(((") == 3)
    IO.puts(santa("(()(()(") == 3)
    IO.puts(santa("))(((((") == 3)
    IO.puts(santa("())") == -1)
    IO.puts(santa("))(") == -1)
    IO.puts(santa(")))") == -3)
    IO.puts(santa(")())())") == -3)
  end

  def solve do 
    IO.puts "and now, the punchline"
    {:ok, input} = File.read "day1.input.txt"
    IO.puts(santa input)
    IO.puts(basement input)
  end

  def basement(s) do
    basement(String.codepoints(s), 0, 0)
  end

  defp basement(_, pos, -1) do
    pos
  end

  defp basement(["(" | tail], pos, floor) do
    basement(tail, pos + 1, floor + 1)
  end

  defp basement([")" | tail], pos, floor) do
    basement(tail, pos + 1, floor - 1)
  end

  def test_basement do
    IO.puts(basement(")") == 1)
    IO.puts(basement("()())") == 5)
  end

end


Day1.solve

8 comments

#idiomatic-elixir

3 2215 8

2016-07-13 16:24:08 UTC

Showing Posts 1 to 8

Show Best Posts
Show All (oldest first)
Show All (newest first)

OvermindDL1

I prefer the classic recursive approach as well, though I’d probably align the santa/2 parts to be more like:

  defp santa([], n)           ,do: n
  defp santa(["(" | tail], n) ,do: santa(tail, n + 1)
  defp santa([")" | tail], n) ,do: santa(tail, n - 1)

Two things though, I notice no clause to handle a non-parenthesis, and this is fine for small inputs but huge inputs then might be better without TCO, basically this:

  def santa(s) ,do: s
    |> String.codepoints
    |> do_santa

  defp do_santa([])           ,do: 0
  defp do_santa(["(" | tail]) ,do: santa(tail) + 1
  defp do_santa([")" | tail]) ,do: santa(tail) - 1

All the above code is untested, but is just my way of doing it.

Also, instead of the testing you are doing there this would be an almost trivial example case for a property testing library if you want to learn something fascinating and useful.

Post #1

orestis

Good call about the alignment of parts (coming from Python I don’t really like the multiple syntax and optional parenthesis, but I can live with them).

I’m not sure I get the part about handling a non-parenthesis, I thought we were supposed to “fail-fast” - if I wanted to ignore any non-parenthesis I’d just add:

 defp santa([_ | tail], n) ,do: santa(tail, n)

At the end, no?

Post #2

OvermindDL1

If you do not want to accept non-parenthesis then yes, fail fast. ^.^
I’m not sure what the requirements of the exercise are so I did not know.

But yes, that is how you could ignore them.

Post #3

orestis

Thanks for the testing links, I didn’t use mix for this so I couldn’t be bothered to use any external stuff.

Can you explain the bit about not using TCO? I thought that TCO was a must as it effectively turns recursion into iteration and you can go to arbitrary lengths without blowing the stack. If I’m not mistaken santa(tail) + 1 will not be TCO.

Post #4

OvermindDL1

Correct, but TCO is not free, and I was typing up a long post but I found a good conversation about it on these forums so deleted it and here is the post that describes it in detail and ‘why’ it is the way it is: Tail Call Optimization in Elixir & Erlang – not as efficient and important as you probably think

In essence, an EVM (Erlang VM) process’s stack is also on the heap and they grow toward each other, so it does not matter which you use from a memory perspective, and overall it is more important to keep memory changes down. So in this specific case TCO would not really hurt, but it is not necessary and would likely be faster without TCO since you have bounded inputs.

The only time TCO should really be focused on is when, as per @rvirding as I recall, only when you have unbounded loops, like a receive loop.

Post #5

gregvaughn

I think that manual recursion approach is something everyone needs to know how to do, and it’s great as a learning exercise. That said, however, I’d expect something more like this in production code:

 def santa(s) do
    s |> String.codepoints
      |> Enum.reduce(0, 
        fn "(", n -> n + 1
           ")", n -> n - 1
        end)
  end

Post #6

orestis

Thanks for that, that does seem nice and understandable. I’m still learning the (many) constructs of Elixir, it didn’t occur to me that even inline functions can have multiple clauses.

In the code linked a lot of people instead use case, but it seems that pattern matching is more idiomatic (if you can use it).

Post #7

gregvaughn

Agreed. Technically you do pattern match even in case statements, but yes, there’s a general preference for doing it in function heads (even anonymous function heads). I have run across a circumstance where I felt the code read better by using a case rather than splitting things up across multiple function heads, but I think that’s just an aesthetic one has to acquire with practice.

Post #8

— All posts loaded —