Match on the end of a pipe (Matchpipe?)

[sebsel]

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

[OvermindDL1]

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. ^.^;

[axelson]

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.

[OvermindDL1]

@axelson

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.

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).

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.

[sebsel]

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).

@OvermindDL1

I use that |> case do result -> ... end pattern a lot .

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.

@axelson

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.

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

[kelvinst]

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

[sebsel]

Oh, nice. There is already a match?(a, b), which returns a boolean, but that one also matches right to left, which can be confusing.

[pera]

@OvermindDL1

I use that |> case do result -> ... end pattern a lot .

Cool, I also use it a lot and was wondering if it was considered a “bad” (as in unreadable) style.

[michalmuskala]

@pera

@OvermindDL1

I use that |> case do result -> ... end pattern a lot .

Cool, I also use it a lot and was wondering if it was considered a “bad” (as in unreadable) style.

Some, including me, do consider it rather unreadable . I’d much rather see:

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

{:ok, result}

or even

{:ok,
 start
 |> Enum.map(&do_something/1)
 |> Enum.filter(&but_without_these/1)}

[lud]

But the case do does not define a result variable usable afterwards. It is not equivalent to the proposed syntax, no ?

[pera]

Yes, @sebsel 's reversed match operator |= is semantically different than piping a case do, but they are similar in some situations.

@michalmuskala

or even

{:ok,
 start
 |> Enum.map(&do_something/1)
 |> Enum.filter(&but_without_these/1)}

The “problem” is that sometimes I need to further process some internal element, like:

start
|> Enum.map ...
|> Enum.reduce ...
|> case do {x, y} -> {Enum.reverse(x), y} end
|> foo

[ityonemo]

Can confirm, I use pipe into case a ton. My only complaint about it is that vscode-elixir highlighting doesn’t respect that pattern

[lud]

I use |> case do a lot but always when I actually have to match against several patterns. I did not think about using it just to transform a value. Stupid me

Anyway I have a small library that I use to bundle all the small utilities I made to work with elixir. I have a public version but with only 2 utilities. I have added a ~> macro to it. I use ~> and not |= because this operator is not available.

[OvermindDL1]

@ityonemo

My only complaint about it is that vscode-elixir highlighting doesn’t respect that pattern

Wait what? It’s bog-standard normal elixir syntax and it absolutely should be accepted. That sounds like a bug. The highlighting works fine in emacs and intellij-elixir at least… o.O

[sorentwo]

It highlights just fine in vim. However, the formatter insists on expanding it from a single line to three.

That’s my only complaint

[OvermindDL1]

Ah I think that’s the mix formatter doing that actually. ^.^;

[sorentwo]

That’s what I meant by “the formatter”. Sorry I wasn’t clearer!

[OvermindDL1]

Sadly the elixir formatter is really opinionated and unchangeable. ^.^;

freedom_formatter has more options, it’s a fork of elixir’s formatter, can PR into it! ^.^

[ityonemo]

to be more specific, it thinks that case is a function because it’s at the end of a pipe, and so it highlights it as a function call, and not a keyword. I’m being super nitpicky. It’s always the little things that drive you insane, mirite?

[pera]

defmacro {:|>, _line, [pipe, match]} ~> expr do
  quote do
    unquote(pipe)
    |> case do unquote(match) -> unquote(expr) end
  end
end
defmacro _ ~> _, do: raise ArgumentError, "~>/2 must be presided by a pipe"

{1,2} |> {x,y} ~> {x+1, foo(y)} etc…