Just updated the README to avoid possible confusion and added a note on how expat patterns could be used to construct data if you provide all bindings, I mean you’ve always had, but with expat you abstract the actual form and give it a name, like this example
defpat ok {:ok, value}
ok(22) # => {:ok, 22}
Yeah, this is definitely my favorite new library. The primary gain from it for me is making things DRYer. Where before I would have map structures repeated in multiple function clauses, e.g.
def handle_cmd(%{"dest_ib" => dest_ib,
"context_ib_gib" => context_ib_gib,
"src_ib_gib" => src_ib_gib} = data, ..) when guard1 do
def handle_cmd(%{"dest_ib" => dest_ib,
"context_ib_gib" => context_ib_gib,
"src_ib_gib" => src_ib_gib} = data, ..) when guard2 do
which has redundancy in the "var_name" => var_name, as well in the function clause level. And dest_ib and src_ib_gib are used across multiple commands in many places. I’m now able to create a single file for the reused patterns:
defmodule WebGib.Patterns do
@moduledoc """
Reusable patterns using expat
"""
import Expat
defpat dest_ib_ %{"dest_ib" => dest_ib}
defpat src_ib_gib_ %{"src_ib_gib" => src_ib_gib}
defpat context_ib_gib_ %{"context_ib_gib" => context_ib_gib}
# ..
end
(NB: I am tacitly going with a _ suffix to indicate a pattern vs the var name, but I’m not sure what other non-word characters are legal in elixir. I would rather prefix the pattern with a single character and would love any suggestions.)
And then I compose them above the function and consume them:
defpat fork_data_(
dest_ib_() =
context_ib_gib_() =
src_ib_gib_()
)
def handle_cmd(fork_data_(...) = data, ..) when guard1 do
def handle_cmd(fork_data_(...) = data, ..) when guard1 do
EDIT: The ... inside the pattern is literal syntax, which helps enormously with DRY. The other .. just means other args.
This is ridiculously more DRY and readable. Definitely a powerful lib you made here! 
Thank you! 
This is a really nice project. Since you are exploring things on the area, here are some challenges/questions you can consider:
Is it possible to extend expat to be a generalization of records? defpat contains an exact subset of the records functionality, which is the pattern matching one. It is also easy to see how defpat could be used for updates, all you need to do is to match on the value and then build another new value of exactly the same shape with the same variables in place except the ones you are replacing, etc.
Have you considered using another operator instead of = for mixing patterns? I believe your mixing of patterns is actually an intersection. If you assume that %{"id" => id} will match all maps with the "id" field, including %{"id" => "foo", "name" => "baz"}, and the pattern %{"name" => name} all maps with a "name" field, including the map mentioned above, when you specify id() = name() you are actually saying it should have BOTH patterns, id() AND name(). If you think of patterns as sets representing the structures they can match on, it is an intersection. Another reason to choose another operator is that the precedence will work in a way it won’t require parentheses, for example: defpat subject id() &&& name(). Here is a list of operators.
There is one feature we could add to Elixir that would allow the library to become more powerful which is to allow guards inside patterns:
def is_foo_or_bar(atom when atom in [:foo, :bar])
Of course nobody would write such in practice but supporting it would allow you to express patterns with guards:
def is_foo_or_bar(foo_or_bar())
Which the Elixir compiler would then rewrite internally as:
def is_foo_or_bar(atom) when atom in [:foo, :bar]
Anyway, this is very exciting and it is close to topics I am currently researching. 
I could expand more on both points above if you are interested. For example, if you are able to generalize defpat to records, you should also be able to generalize it for map updates, and if you define a pattern such as:
defpat foo_bar_baz %{"foo" => {bar, baz}}
And then allow someone to update the nested tuple like this:
map = %{"foo" => {1, 2}, "hello" => "world"}
foo_bar_baz(map, bar: 3)
#=> %{"foo" => {3, 2}, "hello" => "world"}
Optimizations could allow you to compile foo_bar_baz to %{map | "foo" => Map.fetch!(map, "foo") |> put_elem(0, 3)}.
Hey José, thanks for your input!
haven’t explored this, but will try and report back how it goes.
Actually, I’m doing nothing with operators in expat. It’s just that if you define a pattern like
defpat foo %{"a" => a}
defpat bar %{"b" => b}
defpat baz(foo() = bar())
baz(...) = %{a: "missing b", c: "unused"} # this would expand to
%{"a" => a} = %{"b" => b} = %{a: "missing b", c: "unused"}
so you are just using the standard = operator to match on two patterns at the same time. I just mentioned it on the README so people could know how to intersect two patterns (will s/mixing/intersect/ that part on the guide)
That would be a nice idea to explore, not sure if guards should be inside of patterns in Elixir tho, and not sure if we do need to extend Elixir for it. Actually when I was writing Expat I got tempted to allow guards but didnt for the sake of simplicity and time (just being lazy actually, got things to do at Spec). But I was thinking of things like:
defpat foo(%{"foo" => x, "bar" => y}) when x in [:foo, :bar] and is_binary(y)
# but the way Expat currenly works, doing
foo(y: 1) # would expand to
%{"foo" => _, "bar" => 1) when _ in [:foo, :bar] and is_binary(1)
# so when ignoring `x` like in the previous example, I'd need to also
# ignore any guard that uses it
# so just to KISS I went for not yet implementing guards
# (wanted to release early an gather feedback)
would be really nice, will see how far I can get and report back to you.
Thanks for reading!
Oh, I see! This is really clever.
My initial impression is that it is only possible with Elixir extensions since (x when ...) = ... is simply not supported today and if you expand a pattern with a guard inside a function signature, Elixir will fail to compile the code. But if you have found workarounds, please let me know!
I thought this also. It was a bit confusing but I just black-boxed it as “this is how you do it”.
I will say, however, that my understanding of Erlang/Elixir patterns was much improved just from looking at this lib. I had thought of patterns as the entire function signature, and I didn’t realize that Erlang docs give each argument match as individual patterns…So I gotta say thanks just for that. Huge improvement on my misconception.
PS I have started to convert my command functions (command pattern) to use this lib. It’s great.
Hey, good news, I’ve just released v1.0, I did a major rewrite as I really wanted (and needed) it to support guards. Wrote much a much better README guide (I guess) and also documented it more.
The only thing I removed from v0 is the ... syntax as it introduced all variables in scope and it was mostly a pain since elixir 1.5. So now you have to be explicit on what you bind.
Hope the guide explains a bit better where this library fits and how it could be used.
<3
Edit. Forgot to mention, for @josevalim, in the example using guards from the readme, expat def just expands the inner patterns and collects (anding) any guards produced by them, and finally just ands those with any from the function definition. here’s the code
Since expat v1.0 it’s now possible to use guards on your pattern definitions, and they will be expanded at the call-site.
Whoo! This now entirely replaces my purposefully gimped (since it was a standards suggestion and not a real library) library of defguard. ^.^
Although I think I still like the syntax of mine better, I just think that it should be built into elixir instead of the highly gimped-in-comparison defguard that it recently got (though it could be expanded in the future…)
I like how you encourage your’s as a constructor too, do the guards apply on that properly?
Not normally, but just for you I’ve added an experimental workaround for that case. See the last commit foo_test.exs. also might be interesting for you ast_test.exs
Lol, I saw it. ^.^
Have you thought about adding a defguard thing too like in mine so someone can add a guard to a def that can add multiple guards and/or matchers like mine? (Mine is purposefully incomplete because I overrode def to do it, which is not shibby, but it was purely an example anyway).