Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FracturedJson

github.com

Post reply on HN
Print view View original

51–60 of 173 posts

Re: FracturedJson

#51

Post by DJBunnies »

Etheryte wrote: post #37
DJBunnies wrote: post #28

While I wish JSON formally supported comments, it seems more sensible (compatible) to just nest them inside of a keyed list or object as strings. { foo: "bar", ans: 42, comments: { ans: "Douglas Adams" } }

Works right up until you get an entity where the field `comments` is suddenly relevant and then you need to go change everything everywhere. Much better to use the right tool for the job, if you want JSONC, be explicit and use JSONC.

Surely it could be suffixed or keyed with a less likely collision target than this very simplistic example. I suppose JSONC and similar exist, although they are rarely used in the wild in contrast to actual JSON usage, compatibility is important.

Re: FracturedJson

#52

Post by imiric »

kstenerud wrote: post #48

This is great! The more human-readable, the better! I've also been working in the other direction, making JSON more machine-readable: https://github.com/kstenerud/bonjson/ It has EXACTLY the same capabilities and limitations as JSON, so it works as a drop-in replacement that's 35x faster for a machine to read and write. No extra types. No extra features. Anything JSON can do, it can do. Anything JSON can't do, it can…

That's neat, but I'm much more intrigued by your Concise Encoding project[1]. I see that it only has a single Go reference implementation that hasn't been updated in 3 years. Is the project still relevant?

Thanks for sharing your work!

[1]: https://concise-encoding.org/

Re: FracturedJson

#54

Post by tracker1 »

Nice... I like using JSON to stdout for logging, this would be a nice formatting option when doing local dev to prettify it without full decomposition.

Re: FracturedJson

#55

Post by vunderba »

Etheryte wrote: post #37
DJBunnies wrote: post #28

While I wish JSON formally supported comments, it seems more sensible (compatible) to just nest them inside of a keyed list or object as strings. { foo: "bar", ans: 42, comments: { ans: "Douglas Adams" } }

Works right up until you get an entity where the field `comments` is suddenly relevant and then you need to go change everything everywhere. Much better to use the right tool for the job, if you want JSONC, be explicit and use JSONC.

Hadn't heard of JSONC, but I've always been a proponent of JSON5 for this reason.

https://github.com/json5/json5

Re: FracturedJson

#56

Post by vitaelabitur »

nurumaik wrote: post #49
vitaelabitur wrote: post #40

I tokenized these and they seem to use around 20% less tokens than the original JSONs. Which makes me think a schema like this might optimize latency and costs in constrained LLM decoding. I know that LLMs are very familiar with JSON, and choosing uncommon schemas just to reduce tokens hurts semantic performance. But a schema that is sufficiently JSON-like probably won't disrupt model path/patterns that much and prev…

Minified json would use even less tokens

Yeah, but I tried switching to minified JSON on a semantic labelling task and saw a ~5% accuracy drop.

I suspect this happened because most of the pre-training corpus was pretty-printed JSON, and the LLM was forced to derail from likely path and also lost all "visual cues" of nesting depth.

This might happen here too, but maybe to a lesser extent. Anyways, I'll stop building castles in the air now and try it sometime.

Re: FracturedJson

#57

Post by jcims »

hnlmorg wrote: post #32
tomtomtom777 wrote: post #25

Earlier quoted context omitted.

I think integration into jq would be both powerful and sufficient.

Powerful but not sufficient. There’s plenty of us who don’t use jq for various reasons.

LLMs have allowed me to start using jq for more than pretty printing JSON.

Re: FracturedJson

#58

Post by odyssey7 »

boxed wrote: post #45
simonw wrote: post #44

Earlier quoted context omitted.

Depends on how comprehensive the test suite is. And OK it's not equivalent to a formal proof, but passing 1,000+ tests that cover every aspect of the specification is pretty close from a practical perspective, especially for a visual formatting tool.

With mutation testing you can guarantee that all the behavior in the code is tested.

UC Berkeley: “Top-level functional equivalence requires that, for any possible set of inputs x, the two pieces of code produce the same output. … testing, or input-output (I/O) equivalence, is the default correctness metric used by the community. … It is infeasible to guarantee full top-level functional equivalence (i.e., equivalence for any value of x) with testing since this would require testing on a number of inputs so large as to be practically infinite.”

https://www2.eecs.berkeley.edu/Pubs/TechRpts/2025/EECS-2025-...

Re: FracturedJson

#59

Post by quotemstr »

Y-bar wrote: post #27
merelysounds wrote: post #19

Earlier quoted context omitted.

This is a reference to YAML parsing the two letter ISO country code for Norway: country: no As equivalent to a boolean falsy value: country: false It is a relatively common source of problems. One solution is to escape the value: country: “no” More context: https://www.bram.us/2022/01/11/yaml-the-norway-problem/

We stopped having this problem over ten years ago when spec 1.1 was implemented. Why are people still harking on about it?

Because once a technology develops a reputation for having a problem it's practically impossible to rehabilitate it.

Re: FracturedJson

#60

Post by __MatrixMan__ »

When I want something more readable than json I usually use nushell. The syntax is almost the same and you can just pipe through "from json" and "to json" to convert: https://gist.github.com/MatrixManAtYrService/9d25fddc15b2494...

What I like about fractured json is the middle ground between too-sparse pretty printing, and too-compact non-pretty printing, nu doesn't give me that by default.

One thing that neither fractured json nor nushell gives me, which I'd like, is the ability to associate an annotation with a particular datum, convert to json, convert back to the first language, and have that comment still be attached to that datum. Of course the intermediate json would need to have some extra fields to carry the annotations, which would be fine.

Post reply on HN