Ah, my apologies. I jumped the gun a little and forgot to give context. The Toy Robot challenge can be found here (javascript - Toy Robot Simulator - Code Review Stack Exchange) but to summarize:

• Place a robot on a 5x5 grid.
• Feed the robot commands such as
  • PLACE 1,1,NORTH # Places the robot on grid (1,1) of the board facing north.
  • MOVE # Move the robot one square in the direction it’s facing
  • LEFT # Turn the robot left
• Ensure that the robot cannot leave the board and prevent illegal behavior

The Command Pattern is a way to abstract behavior (the commands that act on the robot) and encapsulate all data necessary to complete the command in one place. I’m unaware of an elixir-based solution, I’m sorry. It might also be that the pattern is expressed naturally in functional code and doesn’t need to be “patternized.”

Right in some sense the “Command Pattern” from OO is just about passing around a data object, and in a functional language all that you pass around is data, so it doesn’t really need a formal name.

The normal thing to do in Elixir here would be to have some sort of %Command{} struct that contained the information a command needed. In reviewing the prompt though a struct is almost more complicated than you need as there just aren’t that many instructions, you could probably just get away with a handful of atoms and maybe a tuple for {:place, x, y}.

Probably the other big question is whether the command should itself have a callback to execute itself, or whether the world should execute the command. If you want to stick with having the command execute itself then that’s fine, but the world needs to run a validity check afterward on the resulting world. It shouldn’t be up to the command to validate the world, the world should validate the world.

Here’s a version that’s in Elixir but feels more Erlang-y, in particular:

• most control flow is pattern-matching
• most heads are single expressions
• everything is made of atoms, tuples, and lists
• the way step accumulates “commands” is modeled after gen_statem’s “actions”. This keeps side-effects like printing to stdout out of functions like run

I find this style useful for small one-off tasks like Advent of Code; bigger and longer-lived code can benefit from investing in more-complex features:

• structs instead of tuples so data is more self-describing
• better modularity, encapsulating things like to_dir / from_dir separately
• polymorphic dispatch (via protocols, etc) to decouple “parsing commands” and “running commands”

But those approaches take longer to write so stay tuned.

defmodule RobotCommands do
  @commands ~r/
    \A(?|
    (?:(PLACE)\ (\d+),(\d+),(NORTH|SOUTH|EAST|WEST))
    | (MOVE)
    | (LEFT)
    | (RIGHT)
    | (REPORT)
    )\z
    /x

  @max_x 5
  @max_y 5

  def read(stream) do
    stream
    |> Stream.map(&String.trim/1)
    |> Stream.map(&Regex.run(@commands, &1, capture: :all_but_first))
    |> Stream.map(&parse/1)
  end

  def parse(["PLACE", x_string, y_string, dir_string]) do
    {:place, String.to_integer(x_string), String.to_integer(y_string), to_dir(dir_string)}
  end

  def parse(["MOVE"]), do: :move
  def parse(["LEFT"]), do: :left
  def parse(["RIGHT"]), do: :right
  def parse(["REPORT"]), do: :report
  def parse(_), do: :nop

  defp to_dir("NORTH"), do: :north
  defp to_dir("SOUTH"), do: :south
  defp to_dir("EAST"), do: :east
  defp to_dir("WEST"), do: :west

  defp from_dir(:north), do: "NORTH"
  defp from_dir(:south), do: "SOUTH"
  defp from_dir(:east), do: "EAST"
  defp from_dir(:west), do: "WEST"

  defguardp in_bounds(x, y) when x >= 0 and x <= @max_x and y >= 0 and y <= @max_y

  def step(command, nil), do: step(command, {nil, []})
  def step(command, {state, outputs}) do
    case run(command, state) do
      {new_pos, new_dir} ->
        {{new_pos, new_dir}, outputs}
      {new_pos, new_dir, new_outputs} ->
        {{new_pos, new_dir}, outputs ++ new_outputs}
    end
  end

  def run({:place, x, y, dir}, _) when in_bounds(x, y) do
    {{x, y}, dir}
  end
  def run(_, nil), do: nil
  def run(:move, {pos, dir}), do: {bound(pos, move(pos, dir)), dir}
  def run(:left, {pos, dir}), do: {pos, rotate_left(dir)}
  def run(:right, {pos, dir}), do: {pos, rotate_right(dir)}
  def run(:report, {pos, dir}), do: {pos, dir, [{:report, pos, dir}]}
  def run(:nop, state), do: state

  defp bound(_, {new_x, new_y}) when in_bounds(new_x, new_y), do: {new_x, new_y}
  defp bound(old_pos, _), do: old_pos

  defp move({x, y}, :north), do: {x, y+1}
  defp move({x, y}, :south), do: {x, y-1}
  defp move({x, y}, :east), do: {x+1, y}
  defp move({x, y}, :west), do: {x-1, y}

  defp rotate_left(:north), do: :west
  defp rotate_left(:south), do: :east
  defp rotate_left(:east), do: :north
  defp rotate_left(:west), do: :south

  defp rotate_right(:north), do: :east
  defp rotate_right(:south), do: :west
  defp rotate_right(:east), do: :south
  defp rotate_right(:west), do: :north

  def side_effects({_robot, commands} = result) do
    Enum.each(commands, &do_command/1)

    result
  end

  defp do_command({:report, {x, y}, dir}), do: IO.puts("#{x},#{y},#{from_dir(dir)}")
end

File.stream!("input.txt")
|> RobotCommands.read()
|> Enum.reduce(nil, &RobotCommands.step/2)
|> RobotCommands.side_effects()

Could you share a link to the problem you are solving? I cannot find one in the repository you provide, and what you are trying to solve (with or without a Elixirish version of the command pattern) is unclear.

This feels like a fun project to tackle with a CLI app, with a graphical interface!

So, I build a Elixir project seed for it, if people want to try solving it that way: challenges/toy-robot at latest · christhekeele/challenges · GitHub

More instructions on how to clone the seed and view my attempt at solving here.