“ Naming a project is always difficult. Since this project is focused on representing changes between JSON documents I naturally started thinking about names like "JSON differ, JSON changes, JSON patch, …". However, most of these names have already been used by existing projects. While I was muttering "JSON, JSON, JSON" it suddenly turned into "JSON, JSON, Jason, Jason Mendoza".”<p>This is a reference from The Good Place and it is an amazing name!
This is an interesting tool for computing minimal diffs, but the result is not very human friendly. If this is your goal and you are looking for something better than diff, have a look at graphtage: <a href="https://github.com/trailofbits/graphtage" rel="nofollow">https://github.com/trailofbits/graphtage</a><p>Also works for XML, HTML, YAML and CSV.
Interesting approach! But aren't JSON arrays a pretty wasteful encoding?<p>Since this is an opaque serialization of an instruction set, why not try to encode more bits per number (JSON floats support lossless integers of many more bits), and moving the "symbol table" (string data) to the end?<p>This way you could also compress redundant symbols into single strings.
I'm super interested in this topic. Recently (and still ongoing) I started on hashing out how to diff large datasets and what that even means.<p>I would love to get an understanding of how the HN crowd sees diffing datasets should be (lets say >1GB in size).<p>Are you more interested in a "patch" quality diff of the data which is more machine tailored? Or is a change report/summary/highlights more interesting in that case?<p>Currently I'm leaning more towards the understanding/human consumption perspective which offers some interesting tradeoffs.
Out of curiosity, what problem did you have that this approach solves?<p>Thinking about diffs, plain text diffs are typically compressed for transport anyway, so you end up with something that's human readable at the point of generation and application (where the storage/processing cost associated with legibility is basically insignificant) while being highly compressed during transport (where legibility is irrelevant and no processing beyond copying bits is necessary).
Have you looked at generating a specialized version of this stack machine for other types than JSON values? It'd be neat to have a version that works directly on data with Haskell's GHC.Generics, or a custom derive in Rust.
Isn't this what <a href="https://tools.ietf.org/html/rfc6902" rel="nofollow">https://tools.ietf.org/html/rfc6902</a> is for?
Add a few more lines of code and you have yourself an operational transformation library for collaborative data structures.<p>You may find this relevant:
<a href="https://github.com/ottypes/json1" rel="nofollow">https://github.com/ottypes/json1</a>
Somehow I'm reminded how patch runs ed beneath and I guess could use more advanced editing commands: <a href="https://news.ycombinator.com/item?id=16767509" rel="nofollow">https://news.ycombinator.com/item?id=16767509</a><p>Also is there enough here to build a turing machine? I guess not, but it does seem pretty close.
How does it decide whether two JSON values are equal? e.g. 1 vs 1.00 vs 1e0. (<a href="https://preserves.gitlab.io/preserves/why-not-json.html" rel="nofollow">https://preserves.gitlab.io/preserves/why-not-json.html</a>)