dynamic.option function about stdlib HOT 12 CLOSED

It's failing because there are two unused variables, both called null_atom. I think this is what is wanted:

pub fn option(
  from dynamic: Dynamic,
  of decoder: Decoder(inner),
) -> Result(Option(inner), String) {
  let null_atom = atom_mod.from_string("null")
  case atom(dynamic), decoder(dynamic) {
    _, Ok(result) -> Ok(Some(result))
    Ok(inner), _ if inner == null_atom -> Ok(None)
    _, _ -> Error("")
  }
}

from stdlib.

Ah, how did I miss that. We cannot really pattern match on the value inside the variable because it thinks it’s a new variable. Thanks!

from stdlib.

I think I would rather keep it simple for now. It is easier to later add to the API rather than remove.

from stdlib.

What would the None values be? The atoms undefined, none and nil?

from stdlib.

Yes, I realized there was a bit of choice here, erlang does a few times use [] for nil a few times as well.
The canonical set you listed above does cover 95% of cases, however I am not sure if you would be endlessly getting asked about the other None cases.

If this is considered a good idea, does a dynamic.result also make sense?

from stdlib.

I was thinking about one for Result, but I couldn't work out exactly how it would behave. It would be nice to coerse the Erlang result types of ok | {ok, A} | error | {error, B}

Perhaps ok and error could use Nil as a default value.

from stdlib.

With OK (the elixir library) I never tackled anything but the tuple varients,

Nil doesn't really work, because you'll need to return Result(Dynamic, Dynamic) and the function won't work if returning Error(Nil) in the error case or Error(Dynamic) in the {error, B} case except at runtime

from stdlib.

Sorry, yes, that's what I meant. It would be a dynamic nil.

from stdlib.

So the only dynamic_option function I am using in reality is one that takes the atom null as a nil value (not one we mentioned above) because it is returned from the pgo library, and I guess using SQL semantics.
I think either this function would have to take a list of values it considers None (which would be quite messy) or it's not likely to be very useful

from stdlib.

Let's do this one :)

from stdlib.

I'm trying to write code for this issue like this:

pub fn option(
  from dynamic: Dynamic,
  of decoder: Decoder(inner),
) -> Result(Option(inner), String) {
  let null_atom = atom_mod.from_string("null")
  case atom(dynamic), decoder(dynamic) {
    _, Ok(result) -> Ok(Some(result))
    Ok(null_atom), _ -> Ok(None)
    _, _ -> Error("")
  }
}

but the generated code is:

option(Dynamic, Decoder) ->
    NullAtom = gleam@atom:from_string(<<"null"/utf8>>),
    case {gleam_stdlib:decode_atom(Dynamic), Decoder(Dynamic)} of
        {_, {ok, Result}} ->
            {ok, {some, Result}};

        {{ok, NullAtom@1}, _} ->
            {ok, none};

        {_, _} ->
            {error, <<""/utf8>>}
    end.

which makes erlang complain:

===> Compiling gen/src/[email protected] failed
gen/src/[email protected]:54: variable 'NullAtom' is unused
gen/src/[email protected]:59: variable 'NullAtom@1' is unused

@lpil is this a bug in the compiler?

from stdlib.

What do you think of having something like option_with_custom_none added along with option that works with null?

pub fn option_from_custom_none(none: Dynamic) -> fn(Dynamic, Decoder(inner)) -> Result(Option(inner), String) {
  fn(dynamic, decoder) {
    case decoder(dynamic) {
      _ if dynamic == none -> Ok(None)
      Ok(result) -> Ok(Some(result))
      _ -> Error("")
    }
  }
}

pub fn option(
  from dynamic: Dynamic,
  of decoder: Decoder(inner),
) -> Result(Option(inner), String) {
  let Ok(null_atom) = atom_mod.from_string("null")
  let null = from(null_atom)
  option_from_custom_none(null)(dynamic, decoder)
}

from stdlib.