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.
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!
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.
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.
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
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!
Hi, that’s a good question. First of all, I’d suggest to define as much paths as possible in compile time, because Pathex tries to optimize as much as possible in compile time. You can take a look at this doc to see the explanations about optimizations. The general idea is to provide constants as arguments, specify mods or annotate the path.
Otherwise, for creating paths in runtime you can refer to one of these examples
The most efficient way to do this is:
use Pathex
import Pathex.Lenses, only: [matching: 1]
case items do
[head | tail] ->
Enum.reduce(tail, path(head), fn right, left -> left ~> path(right) end)
[] ->
matching(_)
end
Or the shorter solution
use Pathex
import Pathex.Lenses, only: [matching: 1]
["quiz", "questions", 0]
|> Enum.reduce(matching(_), fn r, l -> l ~> r end)
Pathex now can be use-d inside functions or anything like this. This is now tested and supported.
Paths inlining is now detected for aliased, imported and macro calls. This is done using Macro.Env.lookup* functions, therefore pathex is compatible only with elixir 1.13 or higher
Spec fixes here and there, project formatting.
By the way, I’ve tested this release against gradient (from gradualizer project) and it seemed to be able to find some errors in specs, while failing to complete checking with exception and a bunch of false positives. And I’ve used mix_unused tool to find some unused functions (which helped me a lot)
This release contains bug fixes and improvements in negative indexes for lists and tuples and improvements for force_* operations. For more information, refer to changelog
For example, force_setting a value in list used to result in something like
iex> force_set! [1, 2], path(4), 0
[1, 2, 0]
And now the empty space is filled with nil like this
This release contains performance improvements, bug fixes and special functions for creating for_update-friendly lenses for structures and records. For more information, refer to changelog