Pathex - a library for performing fast actions with nested data structures

Hi there,

I’ve been working on a Pathex library for quite a while now, and I’ve finally managed to create a release which is able to cover all requirements in nested structures access. Think of Pathex as Elixir’s Access but on steroids, or like Clojure’s Spectre but easier to learn and more efficient.



  1. Efficient in time. It’s 2-5 times faster than Access. HTML manipulations with Pathex are 5 times faster than Floki. To achieve this efficiency, Pathex generates pattern-matching cases at compile-time.

  2. Easy to use. Pathex is like a Map or Enum module, but for any structures. At it’s tiny core, it has everything you might need in your development needs. Errors are very descriptive. And I’ve put some effort into the documentation to be easy to navigate

  3. Functional. Pathex is built around functional lens idea, but it differs in some ways from it.

  4. Rich toolkit. Pathex works fine with lists, tuples, maps, structures, nested structures like AST or HTML. Pathex is reusable, because composition of two paths creates another path and so on.


Feedback is really appreciated. I’d like to know what you’re thinking about library design because this library tries to extend the language!


Great project and documentation!


This looks great and I already have some use cases for it.

I like the design too - like the separation of the definition of the paths. I can see it would allow for cleaner code: separation of the definition of the structure of your data from the code that manipulates it.

1 Like

This looks awesome, great work!

I was looking at the Lenses docs and it wasn’t really clear to me the difference between matching and filtering (both the description and the examples are exactly the same)

Doc content in general is really good, but maybe some reordering could be helpful to clarify some things, e.g: cover the combinator syntax before the examples in the cheat sheet.


Thanks, I’ll a basic syntax in the Cheatsheet

The difference between matching and filtering is that
matching accepts pattern as a predicate. For example

iex> admin_lens = matching(%{role: :admin})
iex> Pathex.view(%User{name: "emoragaf", role: :admin}, admin_lens ~> path(:name))
{:ok, "emoragaf"}
iex> Pathex.view(%User{name: "hissssst", role: nil}, admin_lens ~> path(:name))

will work only with values, which match the pattern %{role: :admin}.

And filtering lens supports any predicate as a function passed into it. For example,

iex> admin_lens = filtering(fn user -> user.role == :admin end)
iex> Pathex.view(%User{name: "emoragaf", role: :admin}, admin_lens ~> path(:name))
{:ok, "emoragaf"}
iex> Pathex.view(%User{name: "hissssst", role: nil}, admin_lens ~> path(:name))

This lens does essentially the same as a matching lens above.

As you can see, every lens created with matching can be expressed with filtering, but matchingis easier to write, read and a is little bit faster than filtering


Loving this. I work with deep (up to 10 levels) sports stats data and this could be my ticket to code reduction. Thanks!

1 Like

Spectre is/was a great idea, though it did not get the adoption it deserved. Not very easy to get started with.

Pathex seems to be an improvement - I was looking for something like that myself, because working with immutable nested structures is a pain.

1 Like