Match on the end of a pipe (Matchpipe?)

pattern-matching
match-operator
pipe-operator

#1

So I have looked for this topic and found similar ones but not actually this one. Forgive me if I missed it.

While I really love Elixirs pipelines, I see myself writing this pattern from time to time:

def some_function(start) do
  result =
    start
    |> Enum.map(&do_something/1)
    |> Enum.filter(&but_without_these/1)

  {:ok, result}
end

For this pattern, people seem to have come up with operators that do things with second or last arguments (I found one of those discussions). I’m not really interested in that, I want to make another point.

In the above pattern, I start reading about a result, then I see start, and then the actions that lead to start. Your eyes notice the pipeline quite fast, you see what happens, but especially when the action after the pipeline is more complicated, you start asking yourself: wait, what did they call the result of this pipeline? To find out, you have to go all the way up to read the variable name.

Put in another way: this way of writing messes with the ordering in which things are happening. First, the start is evaluated, then the pipeline is run, and only after that the match is completed which gives result a value.

I think it would be nice to be able to write it like this:

def some_function(start) do
  start
  |> Enum.map(&do_something/1)
  |> Enum.filter(&but_without_these/1)
  >>> result

  {:ok, result}
end

This removes some indentation and reads nicely in order of what happens when. It might even stop the questions for |2>? You can just start a new pipeline after the first one with this variable where-ever you want.

Oh, and it’s a pattern match, so it’s quite powerful, as you know.

def some_function(start) do
  start
  |> Enum.map(&do_something/1)
  |> Enum.filter(&but_without_these/1)
  >>> [first | _]
  Enum.zip(start, first)
  |> Enum.reduce(&more_transforms/1)
  >>> result

  {:ok, result}
end

Note: I used >>> here because it’s one of the available custom operators, but I think => would be prettier (but probably taken) or <| (but that’s not available). Here’s a very naive macro to make it work:

defmacro left >>> right do
  {:=, [], [right, left]}
end

Again, if this has been proposed too many times, please pardon the intrusion :slight_smile:


#2

There are all kinds of useful libraries and patterns, but if you want to stick with stock Elixir then I would do (and do) this:

def some_function(start) do
  start
  |> Enum.map(&do_something/1)
  |> Enum.filter(&but_without_these/1)
  |> case do result ->
    {:ok, result}
  end
end

I use that |> case do result -> ... end pattern a lot. I know that not everyone likes it but I find it significantly more readable then misplaced variable definitions. Now if only we had proper monad’y do blocks without a library. ^.^;


#3

If we’re talking about the specific problem of wrapping in an :ok/:error tuple I actually have a little helper that I find quite useful in my code.

defmodule MyApp.Utils do
  def wrap_in_ok(input), do: {:ok, input}
end

Using that changes the sample code to just:

def some_function(start) do
    start
    |> Enum.map(&do_something/1)
    |> Enum.filter(&but_without_these/1)
    |> MyApp.Utils.wrap_in_ok()
end

Of course this is ignoring @sebsel’s larger point about defining new bindings at the end of pipelines. For that I would think that stylistically that might mean that your pipeline/function is too long and might benefit by moving the whole pipeline into a new function. Of course the correct approach depends on the concrete problem at hand.


#4

For non-kernel things I use the Exceptional library most often, so with it then it would be:

def some_function(start) do
  start
  |> Enum.map(&do_something/1)
  |> Enum.filter(&but_without_these/1)
  |> to_tagged_status()
end

But the case way is useful for ‘generic’ handling of the value without needing to make a new function (which you should always do, but I generally don’t if it’s only a line or two in size and just use the case instead). :slight_smile:

EDIT: For note, to_tagged_status/1 is a lot more than just an &{:ok, &1}.() wrapper, it returns either an :ok or :error tuple depending on the value. If the value is an exception then it wraps it’s exception message in the :error tuple. If it’s already an error or ok tuple then it passes it through unchanged.

iex(devserver2@127.0.0.1)9> 42 |> to_tagged_status()
{:ok, 42}
iex(devserver2@127.0.0.1)10> nil |> to_tagged_status()
{:ok, nil}
iex(devserver2@127.0.0.1)11> {:ok, :blah} |> to_tagged_status()
{:ok, :blah}
iex(devserver2@127.0.0.1)12> Enum.OutOfBoundsError.exception("error message") |> to_tagged_status()
{:error, "error message"}
iex(devserver2@127.0.0.1)13> {:error, :blorp} |> to_tagged_status()
{:error, :blorp}

I quite like the style of returning ok/error tuples, raw ok values, or exceptions. It is quite useful I’ve found. :slight_smile:


#5

I realize I am really just asking for a “reversed match operator” (so it should contain a =), and this is it’s primary use-case, but there could be others.

a = 1
2 - 1 |= ^a

start
|> some_function()
|= result

The downside to such an operator would be that it’s yet another thing to learn, and that the error ‘no match of right hand value’ becomes cryptic (for it’s now the left hand value).

I was aware that there are other solutions, but I like piping into a case for this! It gives a nice reminder that if you make a specific match, you should add a branch for when it does not match. :smiley:

Yeah, I could have made my example harder, because that was not my point. I would like to actually see the tuple in the function tho, that reads faster :slight_smile:


#6

I created this pull-request to a lib I have: https://github.com/kelvinst/plumbing/pull/1

Basically introducing a match macro, that you could use like:

import Plumbing

1
|> Kernel.+(2)
|> match(a)

match(%{x: 3}, %{x: ^a})

I tried the |= operator, but elixir syntactic parser does not allow it. And at the end, I like the “functiony” look of match