Should one use pipes or with?

happy and throw are not mentioned during this discussion, I wonder why that is.
It seems to me that expressing a |> clear |> happy(path) is the most important benefit of using pipes.
Functions can be designed to throw when they are not happy.
Data that is thrown can be formatted in such a way that it is easy to catch just like you would catch an unhappy with outcome using else.
Combining |>, throw and catch can help express both the happy path and every unhappy scenario very clearly.
Of course I’m not saying that a public api should throw stuff.

If you’re just simply threading a success result through to the next function then you would want to look at the previously mentioned GitHub - CrowdHailer/OK: Elegant error/exception handling in Elixir, with result monads. · GitHub

(or GitHub - expede/exceptional: Helpers for Elixir exceptions · GitHub if you want something more monady)

The with examples given above all seem like they could be cleaned up with macro to handle threading the success result back around into the next function. Similar to pipe, actually. Would that be possible? Or are real-life uses not so neat and tidy?

I try to use with as much as I can and for all other stuff I like sage, sage | Hex

See the post: https://medium.com/nebo-15/introducing-sage-a-sagas-pattern-implementation-in-elixir-3ad499f236f6

It’s not about using pipe or not. The fundamental question is how to control flow and where the logic should be placed.

• with is good for orchestration func (handling all control flow) calling simple func (returning ok/error tuple, focusing on single job)
• pipe operator is good for pipeline funcs that are aware of context.
  • this control flow is delegated to individual func.

Note that it’s not all or nothing. For example, you may use pipe for funcs for data transformation or small control flow.

There is no one size fits all … best is highly context sensitive.

Without a library the with/1 pattern demonstrated by @tme_317 is probably the best starting point.

def something(args) do
  with {:step1, {:ok, result1}} <- {:step1, task1(args)},
       {:step2, {:ok, result2}} <- {:step2, task2(result1)} do
  {:ok, result2}
else
  {_, error} -> error
end

Granted it isn’t particularly pretty but it gets the job done and there is some flexibility that goes beyond what the pipe can do.

Now I suspect that this has more to do with your own frustration - “why isn’t this already a solved problem within the language itself”.

Likely because this “problem” doesn’t actually come up all that often.

Erlang introduced {:ok, result}/{:error, reason} more than likely as a poor mans Either (or Result) type.

Given how optimized pattern matching is :ok/:error tuples are a good enough solution.

Putting my C hat on, I can easily imagine an Erlang programmer cringing at the thought of wasting precious function reductions passing an error value around through function calls just to comply with ROP. The attitude would be to drop everything and return the error value promptly - even if it meant a few more lines of code here and there, as long as it benefitted the runtime budget.

The Elixir pipe operator is merely a DevX function application feature that takes the place method chaining in OO languages and is almost as useful as function composition. The pipe operator never meant to take on the :ok/:error tuple issue.

That is really the domain of with/1. But in order to make it useful beyond just plain {:ok, result}/{:error, reason} values it is also more verbose than a pipe. And finally with/1 will quit at the first sign of trouble and is capable of soaking up all sorts of sins committed by the functions that it calls.

The same argument can be made against factoring a 1000 line function into multiple smaller functions. To me those smaller functions add value as long as they are well named and often they tend to make the code more declarative.

I hate trying to figure something like this out:

self.addEventListener('activate', event => {
  console.log('Activating new service worker...');

  const cacheWhitelist = [staticCacheName];

  event.waitUntil(
    caches.keys().then(cacheNames => {
      return Promise.all(
        cacheNames.map(cacheName => {
          if (cacheWhitelist.indexOf(cacheName) === -1) {
            return caches.delete(cacheName);
          }
        })
      );
    })
  );
});

I find this much easier to reason about:

// Activate event
const cacheWhiteList = [staticCacheName]
const isObsoleteCache = name => cacheWhiteList.indexOf(name) === -1
const selectCachesToDelete = cacheNames => cacheNames.filter(isObsoleteCache)
const deleteNamedCache = name => self.caches.delete(name)
const deleteCaches = cacheNames => Promise.all(cacheNames.map(deleteNamedCache))

function activateListener (event) {
  console.log('Activating new service worker...')
  event.waitUntil(
    self.caches.keys().then(
      selectCachesToDelete
    ).then(
      deleteCaches
    )
  )
}

self.addEventListener('install', installListener)
self.addEventListener('fetch', fetchListener)
self.addEventListener('activate', activateListener)

… code for which some members in the JS community would probably lynch me for

• but now I don’t know how everything works
• like that’s the whole point
• maximize the ignorance of every function

So when you have a 10 function pipeline (or with/1) then maybe, just maybe that pipe is spanning multiple, distinct transformations that are just begging to be named for the benefit of future maintainers.

Can’t you raise on unexpected errors?

I personally use with when errors are expected, and pipelines with functions that raise when errors should not happen (the boundary is not always obvious):

def my_fun(url) do
  res =
    url
    |> f1()
    |> HTTPoison.get!()
    |> Jason.decode!()
    |> f2()
    |> f3()

  {:ok, res}
rescue
  %HTTPoison.Error{} ->
    {:error, :http_download_error}

  %Jason.DecodeError{} ->
    {:error, :json_parse_error}

  e ->
    {:error, e}
end

with can be a true life saver especially when you communicate with other systems, I talk about it here. Basic idea is first validate my own data, then validate with external system(s) then insert locally. Or authentication where things might go wrong at multiple places.

|> just shows a transformation of input values to output values to me. I usually don’t expect error handling to take place there but just a smooth transformation.

Basically you can say, that regular macros are syntactic sugar. Even those that are created by third party libraries or yourself. SpecialForms though are actual syntax.

So, it is a special kind of macro, correct? Or is it something else completely different but it is documented in such a way for users to better understand?