sphaso / noether Goto Github PK

I was wondering if could be useful to modify the unwrap function in order to accept a function as second param (matching).
The implementation:

@spec unwrap(any()) :: any()
def unwrap(a, b \\ nil)
def unwrap({:ok, a}, _), do: a
def unwrap({:error, error}, or_else) when is_function(or_else, 1), do: or_else.(error)
def unwrap(_, default), do: default

Otherwise what about something like the rust unwrap_or_else function in Result?

In my mind could be very useful when you want to get the either :ok value or raise the :error. Or maybe when you need to transform the error into something else.

What do you think?

Thank you, Simone

Please add a method called map_all.

Given a list of values and a function (any -> {:ok, any} | {:error, any}) should return {:ok [any]} with mapped values if every mapped value result in {:ok, any}. {:error, any} otherwise (maybe the first error returned by function)

Big picture:
having a function that applies another function on each element until it results in an {:ok, a} and stops at that point.

Example:
find the first format that matches a particular date. The "first matching" function iterates over the list of formats, applies Timex.parse and returns the first result matching an :ok pattern

Naive-ish implementation using the existing choose:

def first_matching(list, f) do
  Enum.reduce(list, {:error, nil}, fn el, acc ->
     Either.map(acc, fn _ -> Either.choose(el, f, & &1) end)
  end)
end

It would be cool to upgrade dialyxir to 1.0.0-rc-7, which also removes the --halt-exit-status flag, being now a default behaviour

Same behaviour, but wraps errors in {:error, _} tuples if they are not already

Could be something like this:

iex> Noether.List.wrap(nil)
[]

iex> Noether.List.wrap(1)
[1]

iex> Noether.List.wrap([1])
[[1]]

It doesn't make sense to keep iterating if we already know how to return.

either module could have a flat_map and flatten to flat nested oks (right value mapped)

Moreover could be useful to implement a map_ok and map_error functions

The examples are all formatted poorly. There's some typos and a link to the Elixir List on the main page.

PR #29 highlighted how there's a set of functions from Scala\Haskell that we haven't considered. In particular Try.map from Scala acts as a functor on Try objects, applying a function in case no exception was thrown.
Currently we have Either.try which maps a function application to an either, i.e., :ok if the function succeeded, :error if an exception was thrown.

A few questions from the top of my head:

• do we need Try.map when the user could use the with construct? (or just map after the Either.try)
• are there other functions outside of Either.try that we could implement?
• would it make sense to treat Try as a separate module (i.e. not piggybacking on either)?

@paolosimone @neslinesli93 @cottinisimone

Consider nil as well in the reduce function.

The current set of functions is a mix between Haskell and Scala. I'd like to keep it more consistent with Haskell.

Two examples:
Either.flat_map is really Either.join

Either.map_error doesn't make much sense, since you end up with stuff like:

   |> Either.map(&Map.get(&1, :create, %{}))
   |> Either.map_error(fn reason -> ... end)

but in Haskell there's just an either function that takes two functions, one for each branch.

Is there anything else?

• add three new collaborators to the mix.exs file
• remember to bump version in the README
• update CHANGELOG
• relese to hex

CircleCI or Travis?

Let's add a vanity badge to see if the build is green on master :P

Similar to fromMaybe in Haskell.

Given a default, it tries to unwrap the value. If it's OK, the ok value is returned, otherwise the default is returned.