4 ms·

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

by theamk 1y ago

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]]}

cryptonector 1y ago
Yeah, I'm going to say NO WAY to that.
SebastianKra 1y ago
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.
- stronglikedan 1y ago
  > 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.
  - Kinrany 1y ago
    The languave server, which in this age of LSP should come from the same project as the language itself.
  - hiccuphippo 1y ago
    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.
- theamk 1y ago
  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.
  - SebastianKra 1y ago
    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.
    - theamk 1y ago
      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.
      - SebastianKra 1y ago
        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.
andrewla 1y ago
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).
- wofo 1y ago
  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!
  - rfl890 1y ago
    I'm an idiot. Nevermind me
    - satiric 1y ago
      The configuration language that is the subject of the article
  - kiitos 1y ago
    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?
    - dmarcotte 1y ago
      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 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/857d585ef26d9f73e080b5f269e7ed7652495fc3/src/commonMain/kotlin/org/kson/parser/Parser.kt#L8-L39 https://github.com/kson-org/kson/blob/857d585ef26d9f73e080b5... [2] https://kson.org/docs/install/#languages https://kson.org/docs/install/#languages [3] https://kson.org/docs/install/#editor-support https://kson.org/docs/install/#editor-support
wofo 1y ago
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 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/ https://kson.org/playground/) and will properly get a warning: ports: - 80 - 8000 - 10000 - 12000 - 14000 Next to that, note that KSON already has an autoformatter, which also helps prevent misleading indentation in files.
- theamk 1y ago
  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.
  - wofo 1y ago
    > 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.
kookamamie 1y ago
Yes, the syntax makes no intuitive sense, whatsoever.
afiori 1y ago
The only sane configuration language is something similar to gron https://github.com/tomnomnom/gron https://github.com/tomnomnom/gron

by theamk 1y ago

cryptonector 1y ago

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

SebastianKra 1y ago

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.

stronglikedan 1y ago
> 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.
- Kinrany 1y ago
  The languave server, which in this age of LSP should come from the same project as the language itself.
- hiccuphippo 1y ago
  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.
theamk 1y ago
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.
- SebastianKra 1y ago
  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.
  - theamk 1y ago
    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.
    - SebastianKra 1y ago
      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.

andrewla 1y ago

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

wofo 1y ago
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!
- rfl890 1y ago
  I'm an idiot. Nevermind me
  - satiric 1y ago
    The configuration language that is the subject of the article
- kiitos 1y ago
  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?
  - dmarcotte 1y ago
    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 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/857d585ef26d9f73e080b5f269e7ed7652495fc3/src/commonMain/kotlin/org/kson/parser/Parser.kt#L8-L39 https://github.com/kson-org/kson/blob/857d585ef26d9f73e080b5... [2] https://kson.org/docs/install/#languages https://kson.org/docs/install/#languages [3] https://kson.org/docs/install/#editor-support https://kson.org/docs/install/#editor-support

wofo 1y ago

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 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/ https://kson.org/playground/) and will properly get a warning: ports: - 80 - 8000 - 10000 - 12000 - 14000 Next to that, note that KSON already has an autoformatter, which also helps prevent misleading indentation in files.

theamk 1y ago
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.
- wofo 1y ago
  > 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.

kookamamie 1y ago

Yes, the syntax makes no intuitive sense, whatsoever.

afiori 1y ago

The only sane configuration language is something similar to gron https://github.com/tomnomnom/gron https://github.com/tomnomnom/gron