That's right, KSON the language is any string that parses successfully as KSON. We have a formal grammar for the language [1], and once we validate/harden the design through our beta, we plan to express that in a spec, and we plan to provide a test suite for external implementations to validate themselves against (likely something similar to https://github.com/nst/JSONTestSuite).
I don't think warnings will be part of the spec, though classes of errors may be specified (TBD). This will allow, for instance, implementations that prioritize pure speed by leaving all the guardrails off and simply replying "NO." when they are unable to parse some KSON (and then possibly falling back to a parse with richer validations?).
But languages are more than syntax, they are also the ecosystem of tools around the language. And for a language to be useful and reliable, that ecosystem of tools needs to be excellent, and it needs to be available on any platform you want to use that language. That's a really important motivator for KSON's multiplatform architecture, which allows us to reach all these platforms[2] and editors[3] (with even more to come!)
Thanks for trying out KSON and having a look at the embed blocks. When embedding text inside text, the price/tax to delimit it must be paid somewhere, as the "KSON turducken" you've cooked up here demonstrates. We are familiar with this dish! Here's how we considered it in the design:
Our design observes that triple+ embedded KSON embed blocks should be rare and are zany enough information architecture that we do not need to cater to them. We accommodate singly-embedded KSON by offering `$/$$` as an alternative embed delimiter that can be used to minimize escaping (fun: if you paste your example in the playground <https://kson.org/playground/> and format it, the formatter will minimize the escaping for you).
The two-char end-delimiter is important to make it trivial to describe the end of a embed block: a `%` embed block ends if and only if exactly `%%` is encountered. This is designed to make it dead simple for humans and (especially) tools to understand the bounds of an embed.
Zig's manually-managed margin approach is interesting. Paying the embedded text price/tax with a manually managed margin is inventive, and does indeed give good whitespace control and skips all escaping. However, having to always manage that margin goes against our goal of having embed blocks facilitate "pure" embedded editing as much as possible---every block that does not contain `%%` can be edited completely in the block's native language.
Hopefully that helps make some of our goals and design decisions more clear. We've worked hard to minimize the cost of embedding while maximizing the clarity, utility and toolabilty of it. Definitely open to ideas on improving our min/max'ing here if folks see opportunities. Come chat with us on Zulip if you've got thoughts! https://kson-org.zulipchat.com/
hjson is new on my radar, but looks like it has some great philosophical overlap with KSON! hjson's "interface for JSON" tagline really resonates. If I understand correctly, hjson helps by not requiring commas, allowing unquoted strings,
and supporting multi-line strings. Our support is similar, though we only use # for comments instead of // and support multiline strings both in embed blocks and regular quoted strings.
Where KSON diverges from hjson is enabling a YAML-like presentation while improving on the YAML experience. And by making the content type of embed blocks a first-class citizen of the syntax, with clear boundaries for the embedded content, editors and IDEs can provide full tooling support (syntax highlighting, validation, etc.) for the embedded code. Importantly though, KSON remains 'plain data'---it's not a runtime that executes code in your configs.
Thanks, i_s. Daniel chiming in here... for functions and variables, we intentionally stay focused on JSON/YAML-equivalent data because the places where JSON or YAML are used as human-edited interfaces (because of their limitations rather than in spite of them) is the slice of the programming stack that KSON is particularly interested in. If the next Kubernetes/GitHub Actions/dbt/etc wants to reach for a language to be their interface, KSON is interested in providing everything YAML offers and more (AND less: less of the problems associated with YAML)
We have a design for KSON constants that we're looking forward to sharing soon, but they will be constant and KSON will still be JSON/YAML-equivalent. For the places where someone wants more programming power in their config, I'm glad people like the folks behind Pkl and Dhall are serving that use case.
Hey zahiman, thanks for all the Qs. Trying to address them:
KSON (stands for: KSON Structured Object Notation) is designed not as an nth standard, but rather as an idea of how to play nice with all n-1 existing standards. Since our comments (we do support comments!) are preserved in formatting and transpilation (provided the underlying language supports comments), you may use KSON as how you edit whatever underlying config file your system wants (currently YAML and JSON are supported, with a clear path to adding other targets like TOML <https://github.com/kson-org/kson/issues/202>)
Why is it better than TOML? We don't insist that everyone agree it is! But here's two ways to contrast them:
- We prefer that KSON's recursive structure makes nesting consistent. You can see for instance in the grammar that a Kson list value is a list of Kson values: https://github.com/kson-org/kson/blob/857d585ef26d9f73e080b5...
- For use cases where folks are hand-editing non-trivial config, especially if they are using embedded code blocks of any kind: if they long for more help from their tooling, KSON makes that tooling possible.
Thanks! KSON is very focused on facilitating a better interface for a user managing config data, so one concrete example of the embed block's purpose is to help anywhere folks are directly editing important/complex multi-line strings in their config (think sql in dbt files, or bash snippets in GitHub Actions, etc).
By making the content type of the embed a first-class citizen of the syntax, together with clear boundaries for the embedded content, editors and IDEs can hook in all their great tooling to the embed blocks. So, you nailed it: being great for devex is exactly the idea.
I don't think warnings will be part of the spec, though classes of errors may be specified (TBD). This will allow, for instance, implementations that prioritize pure speed by leaving all the guardrails off and simply replying "NO." when they are unable to parse some KSON (and then possibly falling back to a parse with richer validations?).
But languages are more than syntax, they are also the ecosystem of tools around the language. And for a language to be useful and reliable, that ecosystem of tools needs to be excellent, and it needs to be available on any platform you want to use that language. That's a really important motivator for KSON's multiplatform architecture, which allows us to reach all these platforms[2] and editors[3] (with even more to come!)
[1] https://github.com/kson-org/kson/blob/857d585ef26d9f73e080b5... [2] https://kson.org/docs/install/#languages [3] https://kson.org/docs/install/#editor-support