"non_nil" shortcut inside with

In my practice I often write something like this:

with value when not is_nil(value) <- some_fun() do
  ...
end

What about something like shortcut for this frequently used case?

with non_nil(value) <- some_fun() do
  ...
end

Unfortunately, I can’t find any way to do it via macroses because as I understand when is a some kind of special form that is handled by compiler.

Yeah, that’s because of how with is implemented, it really should have been a macro itself so it doesn’t have these weird and surprisingly inconsistent edge cases.

In short, no, I’ve not found anyway to enhance with like that without just flat-out replacing it, which is entirely an option, there are some good libraries that already have. :slight_smile:

It’s exactly the same as it is with case as well as in function heads:
my_function(not is_nil(x), y) is invalid. I really don’t get what you find so inconsistent with with?

iex(1)> defmodule MyMacros do
...(1)>   defmacro non_nil({binding_name, _, binding_context} = value \\ quote(do: value))
...(1)>     when is_atom(binding_name) and is_atom(binding_context) do
...(1)>     quote(do:  unquote(value) when not is_nil(unquote(value)))
...(1)>   end
...(1)> end
{:module, MyMacros,
 <<70, 79, 82, 49, 0, 0, 5, 240, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 170,
   0, 0, 0, 18, 15, 69, 108, 105, 120, 105, 114, 46, 77, 121, 77, 97, 99, 114,
   111, 115, 8, 95, 95, 105, 110, 102, 111, ...>>, {:non_nil, 1}}
iex(2)> import MyMacros
MyMacros
iex(3)> with non_nil(value) <- :bloop do value end
** (CompileError) iex:3: undefined function when/2
    expanding macro: MyMacros.non_nil/1
    iex:3: (file)
iex(3)> case :bloop do non_nil(value) -> value end
** (CompileError) iex:3: undefined function when/2
    expanding macro: MyMacros.non_nil/1
    iex:3: (file)
iex(3)> # And yet expanding it manually and it works, this is just one of multiple reasons that 'most' special forms are inherently broken
nil
iex(4)> quote do case :bloop do non_nil(value) -> value end end |> Macro.prewalk(&Macro.expand(&1, __ENV__)) |> Code.eval_quoted([]) |> elem(0)
:bloop

It’s expanding into the proper AST node for both case and with, so it should work, it is only because they are special forms not coded to match the rest of the language that they are not. It would obviously not work in a function head because it doesn’t go into a single AST node but rather would have to be split out into two calls instead (I.E. def my_function(x when not is_nil(x), y) makes no sense, but case ... do x when not is_nil(x) -> ... end does make sense, and yet you cannot replace it with a macro of case ... do non_nil(x) -> ... end even if non_nil(x) is just as trivial as defmacro non_nil(v), do: quote(do: unquote(v) when not is_nil(unquote(v))) even though it is AST-identical, thus inconsistent, and even more so with with because it is a weird magical multi-arity function along with for unlike everything else in the language).

I mean I can see that having everything as proper macros might be desirable, but all of them work the same. You need to bind the value to a variable before you can use the variable in a guard clause.

with non_nil(value) <- :bloop do value end

I’d consider that inconsistent with how the rest of the language works and I’d consider how it works with function headers here as well. Where is the value defined that’s been used with non_nil/1? Given that guard clauses in function heads don’t work well with arbitrary macros I also don’t see it as an outlyer that pattern matches in for, case, with would work vastly different.

Just for fun…

After looking into sources I’ve found that with uses :elixir_utils.extract_guards to process guards. So potentially it’s possible to implement something like “inline guards” (may be and for functions too) if rewrite this code:

extract_guards({'when', _, [Left, Right]}) -> {Left, extract_or_guards(Right)};
extract_guards(Else) -> {Else, []}.

with

extract_guards({'when', _, [Left, Right]}) -> {Left, extract_or_guards(Right)};
extract_guards(Else) -> extract_inline_guards(Else).

extract_inline_guards({'non_nil', _, [Arg]}) -> {Arg, [...]}; % ... is quoted for `when not is_nil()`
extarct_inline_guards({'integer', _, [Arg]}) -> {Arg, [...]}; % ... is quoted for `when is_integer()`
extract_inline_guards(Else) -> {Else, []}.

thats gives somethink like this:

with non_nil a <- some_fun(),
     integer x <- other_fun() do
  ...
end

Don’t take this comment seriously )

Anyway, @OvermindDL1 - thanks for a quick reply :wink:

It’s defined via the value in that expression, which would be more clear perhaps without the parenthesis:

with(
  non_nil value <- :bloop,
  do: value
)

And yet it is not? You can define a value just fine via a macro and indeed that is done in many cases in many libraries. As well as you didn’t have to specify a value to bind to, with my above macro you could just as well do:

with(
  value = non_nil() <- :bloop,
  do: value
)

That is why I often have default values in my macro’s for such bindings, so either method works just fine. :slight_smile:

They work just fine if the macro is written to only return guard-safe calls:

iex(1)> defmodule MyMacros do
...(1)>   defmacro is_not_nil(value), do: quote(do: not is_nil(unquote(value)))
...(1)> end
{:module, MyMacros,
 <<70, 79, 82, 49, 0, 0, 4, 200, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 150,
   0, 0, 0, 15, 15, 69, 108, 105, 120, 105, 114, 46, 77, 121, 77, 97, 99, 114,
   111, 115, 8, 95, 95, 105, 110, 102, 111, ...>>, {:is_not_nil, 1}}
iex(2)> import MyMacros
MyMacros
iex(3)> defmodule Bloop do
...(3)>   def my_func(x) when is_not_nil(x), do: x
...(3)> end
{:module, Bloop,
 <<70, 79, 82, 49, 0, 0, 4, 100, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 131,
   0, 0, 0, 14, 12, 69, 108, 105, 120, 105, 114, 46, 66, 108, 111, 111, 112, 8,
   95, 95, 105, 110, 102, 111, 95, 95, 7, ...>>, {:my_func, 1}}
iex(4)> Bloop.my_func(42)
42

:slight_smile:

Actually it is on purpose that they don’t support macro’s in those positions, so sadly it won’t be fixed. However, you can of course make your own library to replace those functions with ones better suited for your purpose. ^.^

I’m actually a fan of having a macro that operates on an entire defmodule declaration to mutate it en-masse to ‘fix-up’ inconsistencies like that (among other things). :slight_smile: