Expat - composable, reusable pattern matching

Huh, looks to save a lot on readability. Is it mostly just for maps?

not just maps, anything that can be a pattern is valid.

Wow. I find it very interesting to say the least.

I notice in your readme (and in your tests) that you are defining the pattern with the string key but matching using the pattern(key: value) which uses the atom keyword syntax. I looked at your macro code, but I’m just not versed enough with macros to quite pin it down…are you somehow converting the keys to atoms in order to match in this way?

Also, am I reading it correctly that the keywords are flattening the keys, e.g. the lat/lng vars in the readme?

And just to “pinch myself” before using this to refactor my controller code, I would be able to do something like the following?:

Before (difficult to read with more form fields):

def fork(conn, %{"fork_form_data" => %{"dest_ib" => dest_ib, "src_ib_gib" => src_ib_gib} = form_data} = params)

to After (composable, and readable):

# Reused patterns
defpat src_ib_gib_p(%{"src_ib_gib" => src_ib_gib})
defpat dest_ib_p(%{"dest_ib" => dest_ib})

# Pattern for just this one function
defpat fork_params_p(%{"fork_form_data" => dest_ib_p(...) = src_ib_gib_p(...)})

def fork(conn, fork_params_p(fork_form_data: form_data, dest_ib: dest_ib, src_ib_gib: src_ib_gib) = params)

Also, I am planning in the future on switching to structs for changeset validation. Would using expat preclude me from using structs?

There aint any key conversion, when you have

defpat foo %{"bar" => baz}

# and then

def something(foo(baz: qux)), do: qux
# Actually you are just replacing one pattern `baz` for another `qux`
# in this example turns out both patterns variables (since assignment is matching an unbound name pattern)
# so instead of a variable `baz` you get a variable `qux`

# (lets use some other kind of things besides maps for examples)

# And because It's just pattern replacement you could place any other pattern instead of `baz`, say:
def something(foo(baz: [first | _tail] )), do: first

# Actually that's how composition works in `expat`,
# if you have something that looks like a function call (its expat-expanded) since anyways function calls
# are not allowed in an elixir pattern.

defpat batman({:bruno, sidekick})
def something(foo(baz: batman(sidekick: robin))) when robin in ["demian"], do: "oh son"
# batman(sidekick: robin) gets expanded to {:batman, robin} you replaced pattern `sidekick` by `robin`

# If you notice, the previous example had batman expanded with an explicit keyword `sidekick: robin`
# that means, that of all `variable` patterns inside `batman` you only care for replacing `sidekick` all others
# we dont care and get replaced by `_` placeholders

# composition takes advantage of this, for example:
defpat latlng {lat, lng}
defpat trip {origin = latlng(), destination = latlng()}

# remember you are just replacing variable-patterns
trip(destination: {0, 0}) # would expand to:  { _ = {_, _}, {0, 0} = {_, _} } notice only `destination` got replaced.

Hope this can explain a bit better how expat works.
Also if you want to help by improving the README that would be great, as my english is almost always a bit weird.

Cheers

Oh and one distadvantage of how things are right now, is that

defpat latlng {lat, lng}
defpat trip {origin = latlng(), destination = latlng()}

# if you replace lat from trip directly  it will be replace in both
trip(lat: 99) # exapnds to { _ = {99, _}, _ = {99, _} }

but you could then define trip like

defpat trip {origin = latlng(lat: orig_lat, lng: orig_lng), destination = latlng(lat: dest_lat, lng: dest_lng)}

but that doesnt seems to have much advantage over a normal pattern tho

oh btw, there’s defpatp for private patterns (wont be visible from other modules it’s defmacropd)

haha sorry for the response by pieces, ^^ last one: using structs, no problem, as previously shown expact doesnt care, if you can pattern match it you can use it.

Ah, so in foo(baz: qux), you’re actually accessing the variable assigned to the value of the key in the original map? In looking at your readme, this confusion arose I think because all of your examples have the same name for both the key/value, e.g. "iq" => iq and "email" => email. I had errantly latched onto the keys being converted. But now I see that you are pulling the variables (which are atoms) out of the pattern and using those for composition. That’s awesome!

Yes, this makes it much clearer to me. Thanks!

Thanks to you! Will definitely update the README with better examples. Thanks !

Possibly. It depends I would think on how much reuse you’re getting from the pattern. The pattern itself looks relatively complex, but you’re giving it a name and then composing it more granularly, and if you reuse it even once, I think it would be a win.

In the OO world (where I came from), I would use granular interfaces and gradually build more complex data structures with them. This looks like a lightweight way of implementing similar interfaces, which is also partly why I was asking about how they’d jive with structs.

I love helping with documentation, but I don’t think I could add anything to your readme as it stands - it is really entertaining.