Your syntax above has the same semantics as haskells do-notation in monads. This special case comes very close to the Maybe-implementation of a Monad and would look roughly like this (assuming magical IO, just working everywhere):

f = do
  user <- fetch_user 1
  cart <- fetch_cart 1
  let order = checkout cart user
  save_order order

Therefore I’d go in fact for that and name that macro monadic. Your block would read as this:

OK.monadic do
  ...
end

The alternative names you mentioned at the end of the post are all four already keywords, top-level-macros or specialforms and have some meaning asigned to them. especially for implies some sort of "loop"ing, since it is heavily known from a plentora of imperative languages.

I like OK.with because

1. It let’s regular elixir users immediately grok that it’s like with.
2. It’s idiomatic English! “I’m OK with that.”

(Try sounds like a try/catch/rescue replacement as opposed to a with replacement)

This is a great lib for playing with macros! That said, I’m personally on efforts around alternatives to with, as I haven’t seen justified benefits.

It’s worth pointing out that you should call out to functions in those cases. Also where you are seeing repetition, I am seeing explicit matching. The issues with Ok is that is hides the true match, and it gets more confusing if you were include a match within the 2nd elem, i.e. %{key: val} <- .... Is the rhs returning a tuple or map? It also breaks down the moment you want to match on something not in an :ok tuple. Using with, you simply add a new clause, with Ok you need to rewrite the entire block.

By that argument I would definetly go with for. For comprehensions are extensible to other monadic types such as the result monad which is what this is. See details of Scala for comprehensions to see more about that.[quote=“chrismccord, post:4, topic:3264”]
The issues with Ok is that is hides the true match
[/quote]

That I consider a feature. The return type of functions used in this syntax must be a result tuple that is easy to describe. In many ways using the :ok tuple is just an implementation detail of a Result Monad. You could have an %OK{value: v}/%Error{reason: reason} struct instead and the behaviour would be the same. For that reason adding a pattern match on the left side is no more complicated.

%User{name: name} <- fetch_user(id)

The return value of fetch user is not ambiguous it is either a success with a user or an Error with single reason. Its far less ambiguous than with which can fail the match in any way. such as :error or false or nil or {:error, too, many, reasons

I definitely think that going for sensible English is the best way to decide. However because the “do” comes before the main actions I think when might be better. Also I want to add an else clause

“I’m OK when doing x, y, z else log”

OK.when do
  user <- fetch_user(1)
  cart <- fetch_cart(1)
  order = checkout(cart, user)
  save_order(order)
else
  error ->
    Logger.warn(error)
end

Note there is no else clause support, Yet.

Exactly. Less noise, less typing, more descriptive. (I use with a lot, so this would be a big win for me - but definitely would need else matching.)

Yes, I think OK.when really captures the fact that it’s a tagged :okexpression and will return the {:ok, result} when the happy path is followed. So this is better than OK.with for that reason, but it would separate itself further from the standard with and might require more mental translation for new readers. On the whole though, I personally lean towards OK.when now.

Searching happy path brought me here :D, turns out, I was experimenting with topics like this some time ago, actually some of my first macro libraries are either similar to Ok or explore something along the lines.

• ok_jose
  This one was my first macro library, I just wanted a result monad, you know for piping ok tagged tuples. But one of my main focus was not to introduce (nor override) existing |> elixir operators.
  Mostly like Ok and also allowed you to define other patterns besides :ok/:error tagged tuples.
  See the defpipe on the README, for example

@doc "Pipes a valid changeset or its ok tagged tuple"
defpipe pipe_valid_changeset do
   valid = %Ecto.Changeset{valid?: true) -> valid
   {:ok, record} -> record
end

# then you can pipe functions that expect valid changesets
{:ok, %User{}}
|> cast(params, [:email, :password])
|> validate_password_conformation()
|> Repo.create
|> new_user_token()
|> pipe_valid_changeset() # no new syntax, just this guy rewrites the pipe

• happy
  Then for cases that were code was not that homogeneous (not always returning :ok/:error tagged tuples) I just wanted to avoid lots of nested case and ended up doing something along the lines of with (back before it landed in Elixir 1.2, which I’ve been pretty much happy_with, except for its commas between match expressions)

• pit
  This one is a bit weird (most things I do are), it was an experiment for having a with made for pipes. That is, you could specify a foo() |> pit(value <- pattern) |> bar() and let bar() take the value from the pattern matched result from foo.

Anyways, I guess it’s an interesting topic, and looks like for others too, since we have some people crafting this kind of things that do similar things (see the ones linked on Ok’s README), if you find any other similar, I’d be interested in looking at it.

BTW, great work on Ok @Crowdhailer, I’d go for OK.with since it’s closer to what with does and when reminds me of guards.

That’s a great point. That would add interference with new users I think and would be confusing. “My vote” is back to OK.with.

It’s certainly an interesting discussion.

I managed to have a very long discussion about it more than a year ago on the elixir google groups.

For my way of thinking I think I have found the best solution. However it’s interesting to see how people have different priorities. I was deliberately strict in what I was working with so I could be terse, however others were far more driven by flexibility

So another argument for using with in this form I have just discovered is the following.

Standard elixir with won’t fail if you accidentally use = instead of <-.

I had the following code

with {:ok, user_id} = Map.fetch(body, "id"),
       {:ok, request_id} = Map.fetch(metadata, "request_id")
do
  # etc
else
  # handle
end

Both of those equals should have been <- but as I had not got a test for the failure case my mistake wasn’t spotted until later.