5 ms·

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 i

by 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
  - kiitos 1y ago
    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

by 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
- kiitos 1y ago
  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