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

hst337

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.

Features

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.
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
Functional. Pathex is built around functional lens idea, but it differs in some ways from it.
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

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

https://github.com/hissssst/pathex

22 comments

#library #access #pathex

84 4835 22

2025-05-02 17:02:05 UTC

First 10 of 22 Posts

josevalim

Creator of Elixir

Great project and documentation!

Post #1

Will-W

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.

Post #2

emoragaf

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.

Post #3

hst337

Thanks, I’ll a basic syntax in the Cheatsheet

Post #4

hst337

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))
:error

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))
:error

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

Post #5

alex_r

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

Post #6

l3nz

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.

Post #7

krstfk

This project is really great, and it’s gonna be a dependency for all of my future projects. I’m only worried that I might end up over using it. I kind of wish there was something like this in the standard library since nested data structures are so pervasive. And I really like the fact that you can throw maps, keyword list, and tuples, nested any which way without worrying about it.
In other words, thank you!

Post #8