Hacker News Reader

Comment by theamk | Hacker News Reader

KSON proudly claims "no whitespace sensitivity", which means "misleading indentation" is back. And it's pretty light on syntax, so there are going to be plenty of mistakes made here.

Here is an example I made in a few minutes:

    ports:
       - 80
       - 8000 - 10000
       - 12000 -
       - 14000

Guess how it parses? answer:

    {"ports":[80,8000,10000,12000,[14000]]}

View on HN

I actually prefer a syntax that is whitespace-sensitive, but should not give meaning to whitespace. That is, the whitespace should not perform a semantic duty, but should be required to be correct.

This is roughly equivalent to saying that a linter can transform the AST of the language into a canonical representation, and the syntax will be rejected unless it matches the canonical representation (modulo things like comments or whitespace-for-clarity).

This sounds like a stricter version of KSON's current warnings for misleading indentation... maybe KSON should have an opt-in feature for this. Thanks for the idea!

I'm an idiot. Nevermind me

The configuration language that is the subject of the article

KSON is a language defined by a grammar/spec, not any specific tool that implements that language, afaict? assuming so, where in that language spec do you define and control "warnings", in a way that other spec-compliant implementations would have equivalent behavior?

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!)

[1] https://github.com/kson-org/kson/blob/857d585ef26d9f73e080b5... [2] https://kson.org/docs/install/#languages [3] https://kson.org/docs/install/#editor-support

my mistake I think in using the term "language" as KSON isn't really a language in any normal definition of "language", it's really I guess a data serialization format, which is fully defined in terms of its (specified) grammar and syntax rules

i.e. until that "formal grammar" which is currently a comment in a Kotlin source file ;) becomes a versioned and reference-able spec that can be implemented by third-parties this is all a bit of a cart/horse dilemma i think maybe

So, opposite of python?

Hmmm that's interesting. KSON actually shows a warning when there's misleading indentation, exactly to prevent this sort of thing! It seems like the detection logic only considers indents after a new line, so it doesn't complain in this case. I just opened an issue to see if things can be tightened up a bit (https://github.com/kson-org/kson/issues/221).

To see misleading indentation warnings in action, you can try the following snippet in the playground (https://kson.org/playground/) and will properly get a warning:

Next to that, note that KSON already has an autoformatter, which also helps prevent misleading indentation in files.

It's config file - I might be editing with "sudo vi", possibly inside docker container, possibly on remote server with awkward connection procedure. Or maybe it'll get generated via some templating mechanism by terraform rules. Or embedded in the code.

If your config format requires autoformatter and/or linter to detect trivial mistakes, it is junk.

> If your config format requires autoformatter and/or linter to detect trivial mistakes, it is junk.

IMO this way of thinking disqualifies lots of legitimate configuration formats, but to each their own I guess.

The only sane configuration language is something similar to gron

https://github.com/tomnomnom/gron

Assuming this takes off, there would be a prettier-plugin that corrects any weird formatting.

When I think about it, any language should come with a strict, non-configurable built-in formatter anyways.

> any language should come with a strict, non-configurable built-in formatter

Would that be on the language, or the IDEs that support it? Seems out of scope to the language itself, but maybe I'm misunderstanding.

The languave server, which in this age of LSP should come from the same project as the language itself.

I'd say a program or subcommand tha comes with the compiler/interpreter. Go has gofmt, zig has zig fmt. The compiler already parses the language so a formatter is only a few steps from that. And being part of the compiler means it's always up to date, there's less bikeshedding, all IDEs and text editors get formatter support easily.

Or you can have languages which do not depend on plugin or formatters to be correct.

If you supposedly human writable config file format is unusable without external tools, there is something wrong with it.

I don't know what weird utopian language you're using, but I have yet to see a one that can't be made unreadable by bad formatting.

Just use a formatter and stop bikeshedding please.

it's config file, so they are often edited in unusual configurations without normal editors present. And they are often not checked in the source code, so there is no standard way to add linter.

And KSON is pretty unique in how bad is it. For example, go to playground and remove a single dot in line 11 (after the books list). Look how the parse tree changes - this 1-character edit means the file is still valid, but the rest of the file is now filed under one of the books.

Do you know of any other config language with this property - a single character removed yields a syntactically correct file which yet parses absolutely incorrectly? I don't. Worst I can think of is maybe one section parses weirdly, or next element of a list. But something like _entire rest of file_ is broken is unique to KSON.

Not sure how big of a deal that would actually be when you consider schema validation by the app, but you have a point.

Btw, I love JetBrain's SSH sync for keeping my config files in VCS and editing them with proper tooling.

Yeah, I'm going to say NO WAY to that.

Yes, the syntax makes no intuitive sense, whatsoever.

Reply on news.ycombinator.com