Output is to standard out, or a file specified by the --outfile switch. Input is from either standard in, or from a file if using the --file switch
I can see potential usefulness of this is in debug mode APIs, where somehow comments are sent as well and are rendered nicely. Especially useful in game dev jsons.
country: no
country: false
country: “no”
Roles: [editor, product_manager]
something:
setting: true
---
another:
thing: falseYaml - just say Norway
Stuff that would have been structurally impossible in XML will happen in yaml. And I don't even like XML.
Both objects desugar to a sequence of segments (lines).
The result is that you can freely mix expression/assignment blocks & statements. Things like switch-case blocks & macro tables are suddenly trivial to format in 2d.
Because comments are handled as right floating, all comments nicely align.
I vibe coded the base layer in an hour. I'm using with autogenerated code, so output is manually coded based on my input. The tricky bit would be "discovering" tables & block. I'd jus use a combo of an LSP and direct observation of sequential statements.
There's an older pure Python version but it's no longer maintained - the author of that recently replaced it with a Python library wrapping the C# code.
This looks to me like the perfect opportunity for a language-independent conformance suite - a set of tests defined as data files that can be shared across multiple implementations.
This would not only guarantee that the existing C# and TypeScript implementations behaved exactly the same way, but would also make it much easier to build and then maintain more implementations across other languages.
Interestingly the now-deprecated Python library does actually use a data-driven test suite in the kind of shape I'm describing: https://github.com/masaccio/compact-json/tree/main/tests/dat...
That new Python library is https://pypi.org/project/fractured-json/ but it's a wrapper around the C# library and says "You must install a valid .NET runtime" - that makes it mostly a non-starter as a dependency for other Python projects because it breaks the ability to "pip install" them without a significant extra step.
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.
{
foo: "bar",
ans: 42,
comments: {
ans: "Douglas Adams"
}
}If it's purely for machine consumption then I suspect you might be describing a schema and there are also tools for that.
That way, the original JSON file stays clean and isn’t polluted with extra data.
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 prevent unintended bias.
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't do.
damnitbuilds•2h ago
And BTW, thanks for supporting comments - the reason given for keeping comments out of standard Json is silly ( "they would be used for parsing directives" ).
Xymist•2h ago
A flathead screwdriver should bend like rubber if someone tries to use it as a prybar.
nodja•1h ago
I don't disagree with the choice, but seeing how things turned out I can't just help but look at the greener grass on the other side.
libria•1h ago
Better not let me near your JSON files then. I pound in wall anchors with the bottom of my drill if my hammer is not within arms reach.
mystifyingpoi•1h ago
While I admire his design goals, people will just work around it in a pinch by adding a "comment" or "_comment" or "_comment_${random_uuid}", simply because they want to do the job they need.
If your screwdriver bends like a rubber when prying, damn it, I'll just put a screw next to it, so it thinks it is used for driving screws and thus behaves correctly.
pixl97•8m ago
speed_spread•38m ago
patates•2h ago
I also would have wanted comments, but I see why Crockford must have been skeptical. He just didn't want JSON to be the next XML.
frizlab•2h ago
cromulent•1h ago
> Insignificant whitespace is allowed before or after any token.
frizlab•58m ago