Per-file parser configs

[eugenesvk]

There are a few options with various trade-offs between readability and ambiguity (e.g., allow unquoted strings risks some kind of NOrway problem) and no one generally correct answer.

I was wondering whether one solution could be to offer flexibility at the file level with the first node per document (with a special reserved node name,kdl in this example)

kdl bare_string=true other_parsing_rule=1

then this indicator would specify in this example whether unquoted strings are allowed or not (with the defaults staying conservative like they're now).
So people willing to accept the risk of extra ambiguity, but have cleaner configs, could simply add bare_string=true at the top

[IceDragon200]

I'd argue the NOrway problems stems from premature casting (in no situation should Norway be treated as false or no), unless it was the country code in which case, should have quoted it to begin with!

In the first place YAML has a lot of aliases:

true = Y|T|Yes|True|1
false = N|F|No|False|0

^ The above are just some instances I've encountered and make for some pretty confusing situations

I'd have no problem with bare identifiers if it wasn't for the sake of it eventually leading to: why can't [some other arbitrary identifier] be treated as [specific keyword] and or [value]; which eventually snowballs as all kinds of new pseudo keywords get added to the language which may or may not break existing bare identifiers.

In a similar vein, adding per-file or even parser configuration only further complicates the implementation as is, I'd rather one parser do one thing (to spec) and that alone, rather than a parser that can do all kinds of things based on some arcane flag(s) or special values in the file.

Because what happens when an older parser is missing these flags and ends up just ignoring them?

If someone really wants bare identifiers, I'd prefer it be treated as a separate dialect of KDL to make it perfectly clear that it's not standard, therefore developers can choose to build their parsers around the core without fear of some special dialect being missing in their implementation.

standard.kdl (standard KDL - the original spec as intended without bells and whistles)

extended.ekdl (extended KDL - which would support bare identifiers and other experimental ideas which may or may not be folded into the original at some point)

In the above case, it would be clear, if you see a file with the .kdl extension you can be sure it's a standard file that your existing tools can handle, version .ekdl which would denote some form of extended KDL and should be handled with extra care.

As an example, kuddle (my elixir implementation of KDL) can support bare identifiers I just have an extra step that identifies them and errors immediately to remain within spec.

[eugenesvk]

eventually snowballs as all kinds of new pseudo keywords get added to the language which may or may not break existing bare identifiers

with YAML the opposite happened, though, right?, the later spec solved the original design issue with too many aliases, so current YAML has no Norway problem

treated as a separate dialect of KDL to

v2 would address it, no?

Because what happens when an older parser is missing these flags and ends up just ignoring them?

same thing when an older parser can't parse v2 files and ends up ignoring whatever ends up in v2 (btw, is that going to be implemented via a .kdl2 extension or a yaml-like version string or something else)?

I'd rather one parser do one thing (to spec) and that alone, rather than a parser that can do all kinds of things based on some arcane flag(s) or special values in the file.

But then you can't have (nice things :)) the "perfect" general config since some of the design decisions have no "perfect" solution and depend on limitations inherent to some use case

For example, for some app config I'd go all in on the nicest editing experience, replace all the {} child indicators with whitespace indentation, ditch all the ", and do something else. In such use cases I don't care about no Norway problems, it's not a web app with serious consequences stemming from such issues

[IceDragon200]

with YAML the opposite happened, though, right?, the later spec solved the original design issue with too many aliases, so current YAML has no Norway problem

The point is, YAML had to double-down on the runaway keywords after the fact, we have the opportunity to not fall into that trap to begin with.

v2 would address it, no?

Only if the rest of the community agrees on having bare identifiers as a norm, and if they do, I hope it comes with a fixed list of keywords.

same thing when an older parser can't parse v2 files and ends up ignoring whatever ends up in v2 (btw, is that going to be implemented via a .kdl2 extension or a yaml-like version string or something else)?

Good point, that is something that will need to be figured out for a migration path.
It's expected that v1 files should be parse-able by v2, but v1 may error or produce the incorrect result (the latter is what worries me more)

But then you can't have (nice things :)) the "perfect" general config since some of the design decisions have no "perfect" solution and depend on limitations inherent to some use case

For example, for some app config I'd go all in on the nicest editing experience, replace all the {} child indicators with whitespace indentation, ditch all the ", and do something else. In such use cases I don't care about no Norway problems, it's not a web app with serious consequences stemming from such issues

And this is what I was worried about, the language becomes something completely different, simply because there were flags to do so, I despise whitespace indentation that denotes structure, since the entire document breaks if you:

• Screw up the indentation
• Don't like the way it's formatted but can't change it because of...
• Messing up relation and hierarchy by over/under indenting a section

[eugenesvk]

not fall into that trap to begin with

sure, so let's not add T in addition to true :)

but v1 may error or produce the incorrect result (the latter is what worries me more)

but this is close unavoidable, afaik forward-compatibility is too hard

And this is what I was worried about, the language becomes something completely different,

Interesting, to me optional whitespace is not completely different, but more like bare identifiers: you can have a more verbose ("" or {}) or less verbose way of expressing some document property

I despise whitespace indentation that denotes structure, since the entire document breaks if you

Valid points, but not for all documents. In that config example from earlier, all the structure has been predefined so you don't do any indentation, just tweak the values. Then only the benefit remains - cleaner reading experience. But if you have longer documents with shifting structures, sure, go with the defaults {} (or if you despite in general, that's also fine, that's the beauty of these types of flags)

[tabatkins]

I'm fairly against this sort of config switch.

I'm also the author of Bikeshed, which does have a jillion little config switches, several of which affect parsing, so I'm not against the concept of parser switches in general. But there's a big difference between a document language and a data language - the latter is a lot more likely to have things copy-pasted between files/snippets, for instance. Also, a document language is mostly plain text (and HTML, in the case of Bikeshed), so there's just less opportunity for any given chunk of copy-pasted content to have anything affected by the parser switches, whereas data languages are usually dense with those opportunities. So having any given piece of the document be affected by parsing switches at the very beginning of the document ends up being a footgun; people have to remember to either copy over the parser switches as well, or modify the text to use the destination's parser config rules.

(This is separate from any discussion about particular parsing discussions, like allowing bare strings.)

[eugenesvk]

But there's a big difference between a document language and a data language

Sorry, a bit confused here, https://kdl.dev

KDL is a document language

So having any given piece of the document be affected by parsing switches at the very beginning of the document ends up being a footgun; people have to remember to either copy over the parser switches as well, or modify the text to use the destination's parser config rules.

Would another bright idea fix this more easily?
Given the KDL feature of arbitrary node nesting, would it be possible to specify the node parsing rules at a node level by wrapping that node within that special kdl bare_string=true other_parsing_rule=1 {copy_pasted_node_now_as_a_child ...}

Maybe even the top-level document node with parsing configs could be simply a wrapper around the document, then there is no conceptual difference between what content you apply parsing rules to: you apply it to whatever you wrap this node around with

[tabatkins]

Sorry, a bit confused here

Sure, words can be used in multiple ways. ^_^ What I mean is that there's a pretty fundamental difference in how a language like HTML and a language like JSON are typically used. You can use either to represent the same stuff as the other, but the core/common use-cases are pretty different. This difference affects how the two should be treated.

would it be possible to specify the node parsing rules at a node level

In theory, tho this doesn't really resolve the issues - you still have to be aware of context you're in if you copy-paste between files. With this you even have to be aware of the parsing context within a single file, so in some ways it's worse.

(This also significantly affects what kind of parsing strategy you can use, if you need to be able to change parsers on the fly. You can't eagerly tokenize, for example.)