Option type compatible with comprehensions in Elixr?

Hi, I have strong Scala background, but I never missed the for comprehensions or the option type.
Instead I use more pattern matching to solve those problems. So a Scala for comprehension with multiple generators becomes a with statement in my elixir solution space.

The with construct will only execute one line at a time, while the comprehensions will act as nested flatMaps.
While some functionality can be shared between the two (the with construct in elixir is a good way of replacing the Result Monad, for instance) comprehensions are more extensive in that they will apply the results of any given generator to those of the other generators.

For this reason, I am interested in see how far I can push comprehensions and how I can use them.

There are a bunch of other versions listed in the readme here.

https://github.com/CrowdHailer/OK

Personally, I do not miss the Option type from F#, though their async and result comprehensions were great. I hated working with the Option/Result type outside of the result comprehension. Noise and ceremony!

I’m personally not a big fan of how monads are always tought boundled with their specific syntax in language XY. Many monads would be considered way less magicy if people actually tought the idea unrelated to syntax, because as you said a option monad in elixir is usually just a {:ok, term} | {:error, term} tuple, but handled with a bunch of explicit case statements. You can see similarities between Functors and Enum.map.

Generally if you want to have for work with “maybe” in elixir I’d just do this:

for result <- list do
  case result do
    {:ok, x} -> handle_x(x)
    err -> err
  end
end

Please do bear in mind that this dicussions’s purpose is not to focus only on the Option type, I am merely using it because I believe it to be the most well known example to people that do FP.

It is fine for people not liking the Option type, what I am really interested in here is in how I can expand this into other (more useful) types and improve my style with the knowledge gained from trying it both ways

Unfortunately, this will not work for multiple generators, unless I have a colossal with statement / case expression at the end for all possible results.

I still appreciate the time you took for your proposal, thank you!

I’d be really curious for a usecase for that. While in theory I can see the problem in that in practice I’d be wondering why one got to needing it in the first place.

Instead of trying to force H-M types into tagged tuples (which they fit most of the time, but not always), what about using a type that already plays nice with Enumerable: a single-element list?

• Some(A) is then represented by [A]
• None is represented by []

That is exactly the approach I am using now:

defmodule ParsingWithOption do
  alias Event

  @type option(t) :: some(t) | nothing
  @type some(t) :: [t]
  @type nothing :: []

  @spec validate_name(String.t()) :: option(String.t())
  def validate_name(name) do
    if String.length(name) > 0 do
      [name]
    else
      []
    end
  end

  @spec validate_end(integer) :: option(integer())
  def validate_end(the_end) do
    if the_end < 3000 do
      [the_end]
    else
      []
    end
  end

  @spec validate_start(integer(), integer()) :: option(integer())
  def validate_start(start, the_end) do
    if start <= the_end do
      [start]
    else
      []
    end
  end

  @spec parse(String.t(), integer(), integer()) :: option(Event.t())
  def parse(name, a_start, an_end) do
    for valid_name <- validate_name(name),
        valid_end <- validate_end(an_end),
        valid_start <- validate_start(a_start, an_end) do
      %Event{name: valid_name, start: valid_start, end: valid_end}
    end
  end
end

However, I am not really sure I am happy with the result.
Getting None at the end of the comprehension is a hell lot more friendly (for my brain) then getting [] and then making the link in my head that [] == None.

And this is having in mind that I am using polymorphic typing with dialyzer, which is the coolest thing ever since … (insert cool thing here).

My function signatures are also totally sick, too bad dialyzer can’t make sense of them and actually catch false positives… (but that is a story for another post. gradient is actually being incredibly useful here).

Some trivial macros can tidy this up a little, if you’re so inclined:

defmodule Blargh do
  defmacro some(x), do: [x]

  defmacro none(), do: []
end

defmodule BlarghTest do
  import Blargh

  def foo(x) do
    case x do
      some(value) -> some(2*value)
      none() -> none()
    end
  end
end