4 ms·

So, this is basically YAML, "but better". I can repeat once more that "easily understood and used by both programmers and non-programmers" is unapologetically s

by krick 6y ago

So, this is basically YAML, "but better". I can repeat once more that "easily understood and used by both programmers and non-programmers" is unapologetically stupid concept that can never succeed. So I see how all of this will sound all too familiar to anybody with a little experience, which makes them to automatically dismiss this YAYAML. But YAML is really quite complicated, and JSON (which shouldn't be used for config files at all) and TOML (which I love and wish it would gain more popularity) aren't exactly alternatives to YAML. So, I would be actually totally ok with "YAML, but better", as a way to deprecate YAML. Now, it is clear from the start that this cannot deprecate YAML, because it doesn't even have booleans and numbers. But, surprisingly, I can accept this as well: ok, let's just assume that being good at dealing with strings may be enough. The problem is, it isn't clear at all from the docs, if this is better than YAML at anything. It raises dozens of questions. I'll start with the most basic ones (using [] as a wrapper/delimiter): how do I represent values [ a], [a ], ["a"] and [""] in this file format?

zelphirkalt 6y ago
What kind of values are [<whitespace>a] and [a<whitespace>] supposed to be? They look like typical YAML syntax traps to me. Why should JSON never be used for configuration? It is sufficient for declaratively expressing anything I have encountered. Do we really need references or other stuff from YAML? For configuration this seems unnessecary, provided that the program, which interprets the result of parsing the JSON is well written.
- krick 6y ago
  > What kind of values are [<whitespace>a] and [a<whitespace>] supposed to be? I don't understand the qustion. They are supposed to be exactly that, [<whitespace>a] and [a<whitespace>]. I assure you, I've encountered many situations, where whitespace at the beginning or the end of the value is actually meaningful for reasons you (creator of the app) have no control over. > Why should JSON never be used for configuration Many reasons, actually, but the most important (IMO) being that original JSON specification doesn't support comments, nor most actual parser implementations do. Configuration file that doesn't support comments is trash and causes very real inconvenience for users. Using additional key values for comments (even if such atrocity doesn't bother you conceptually) isn't a solution in many cases (for example, when your intention is to comment out a list item).
  - 0df8dkdf 6y ago
    Or you can do it this style, but yeah, good point. I can see now why a lot of apple config files are still XML. https://www.freecodecamp.org/news/json-comment-example-how-to-comment-in-json-files/ https://www.freecodecamp.org/news/json-comment-example-how-t...
  - reificator 6y ago
    > original JSON specification doesn't support comments Just for the record, JSON initially had comments and they were later removed according to Douglas Crockford.
    - mrtweetyhack 6y ago
      So you're saying JSON doesn't support comments
  - zelphirkalt 6y ago
    It is only now, that I realize, that [<whitespace>a] and [a<whitespace>] are really supposed to be 1 string inside a list. However, I already see problems with this kind of syntax: [<whitespace>a,<whitespace>b] How will this be interpreted/parsed? Will there be a whitespace before "b" after parsing? That would mean, that I am not able to separate visually more clearly, by adding a whitespace between list elements, which is widely considered to be a good practice in programming languages. The reason is readability. The next thing is, that on the same line whitespace is added, but what about multiple lines defining a list? Here we do not add the line breaks and indentation to the string. It's not consistent in this way. So I personally would never write string like that. I would always make use of quotes in such situations and probably in YAML in general, simply to make it clear, that I do wish to have the leading whitespace in the string, and it is not simply a typo, resulting from removing a former first element from the list. JSON is limitting, but for configuration I think it's kind of limitations are often good. With comments in JSON I am still not sure, because sometimes I'd like to write them there, but would not like to include another dependency, only to be able to parse away the comments from JSON. Then I better write good docs elsewhere.
- user5994461 6y ago
  JSON lacks comments and will fail for a missing or extra comma, so it's not great for configuration written by humans. You can use HJSON which is the json with comments. It's fully compatible with json so easy to introduce into anything that does json. https://hjson.github.io/ https://hjson.github.io/
  - gsliepen 6y ago
    Failing with an extra comma also makes it harder than necessary to write JSON by machines.
  - dzhiurgis 6y ago
    I'd rather take "extra comma" failure than "extra space" space failure. First one can be caught by any IDE, second one will take you a couple of minutes to find out (when building CI for example).
  - westurner 6y ago
    JSON5 also supports comments and multiline strings with `\`-escaped newlines: https://json5.org/ https://json5.org/ Triple-quoted multiline strings like HJSON would be great, too.
- reificator 6y ago
  [<whitespace>a] could be a markdown string that begins with code.
msla 6y ago
I have an even stupider question: How do I have a key with a colon at the end? this:: right this: left Will my program be able to tell its right from its left?
pydry 6y ago
>basically YAML, "but better" That was my intention behind this, too: https://github.com/crdoconnor/strictyaml/ https://github.com/crdoconnor/strictyaml/ The general structure of YAML is fine I think but its feature set grew a little bit out of control. The "cleanliness" of the format leads to one of its inherent weaknesses - syntax can't be used to encode type information so you either need a schema to encode type information (strictyaml approach) or have magic conversions (yaml approach) or to assume strings (strictyaml w/o schema/nestedtext). The interesting thing I discovered about schemas building this is that it kind of pays to make them extensible and build them in a turing complete language. Schema validation done using a non-turing complete language (e.g. jsonschema) allows for cross language usage but it ends up being a kind of blunt object.
simonh 6y ago
> I'll start with the most basic ones (using [] as a wrapper/delimiter) So far as I can tell, this doesn’t use [ or ] in its syntax at all, so all the values you give would be represented exactly as strings without any problem.
- reificator 6y ago
  > So far as I can tell, this doesn’t use [ or ] in its syntax at all Yes, that's why the GP chose those characters to delimit their example strings. I'll try again using ` characters to delimit the example strings. > so all the values you give would be represented exactly as strings without any problem. But what would those string representations hold? If I parse the below strings in a javascript context, what would I get? ` a`, `a `, `"a"` and `""` Do I get this? " a", "a ", "\"a\"" and "\"\"" Or do I get this? "a", "a", "a" and "" Or do I get something inbetween?
  - simonh 6y ago
    OK, I got it. I still don't see the problem. The examples include strings starting with whitespace (One of the multi-line strings), so that's not a problem. Single line strings start with the first character after the colon and a space. If that happens to be a space character, so be it. Strings are terminated by a newline, so trailing spaces aren't a problem. Quote characters are just characters with no special meaning in this format, so those aren't a problem either. Unless the library implementing this format has a bug, there shouldn't be any issues.
westurner 6y ago
From "The description of YAML in the README is inaccurate" https://github.com/KenKundert/nestedtext/issues/10 https://github.com/KenKundert/nestedtext/issues/10 : > I will mention something else. The section about the "Norway problem" is not quite accurate. Some YAML loaders do in fact load no as false. These are usually YAML 1.1 loaders. YAML 1.2's default schema is the same as JSON's (only true, false, 'null and numbers are non-strings). > Any YAML loader is free to use any schema it wants. That is, no loader is required to to load no as false. Good loaders should support multiple schemas and custom schemas. The Norway problem isn't technically a YAML problem but a schema problem. > imho, YAML's biggest failing to date is not making things like this clear enough to the community. > Note: PyYAML has a BaseLoader schema that loads all scalar values as strings.

by krick 6y ago

zelphirkalt 6y ago

What kind of values are [<whitespace>a] and [a<whitespace>] supposed to be? They look like typical YAML syntax traps to me. Why should JSON never be used for configuration? It is sufficient for declaratively expressing anything I have encountered. Do we really need references or other stuff from YAML? For configuration this seems unnessecary, provided that the program, which interprets the result of parsing the JSON is well written.

krick 6y ago
> What kind of values are [<whitespace>a] and [a<whitespace>] supposed to be? I don't understand the qustion. They are supposed to be exactly that, [<whitespace>a] and [a<whitespace>]. I assure you, I've encountered many situations, where whitespace at the beginning or the end of the value is actually meaningful for reasons you (creator of the app) have no control over. > Why should JSON never be used for configuration Many reasons, actually, but the most important (IMO) being that original JSON specification doesn't support comments, nor most actual parser implementations do. Configuration file that doesn't support comments is trash and causes very real inconvenience for users. Using additional key values for comments (even if such atrocity doesn't bother you conceptually) isn't a solution in many cases (for example, when your intention is to comment out a list item).
- 0df8dkdf 6y ago
  Or you can do it this style, but yeah, good point. I can see now why a lot of apple config files are still XML. https://www.freecodecamp.org/news/json-comment-example-how-to-comment-in-json-files/ https://www.freecodecamp.org/news/json-comment-example-how-t...
- reificator 6y ago
  > original JSON specification doesn't support comments Just for the record, JSON initially had comments and they were later removed according to Douglas Crockford.
  - mrtweetyhack 6y ago
    So you're saying JSON doesn't support comments
- zelphirkalt 6y ago
  It is only now, that I realize, that [<whitespace>a] and [a<whitespace>] are really supposed to be 1 string inside a list. However, I already see problems with this kind of syntax: [<whitespace>a,<whitespace>b] How will this be interpreted/parsed? Will there be a whitespace before "b" after parsing? That would mean, that I am not able to separate visually more clearly, by adding a whitespace between list elements, which is widely considered to be a good practice in programming languages. The reason is readability. The next thing is, that on the same line whitespace is added, but what about multiple lines defining a list? Here we do not add the line breaks and indentation to the string. It's not consistent in this way. So I personally would never write string like that. I would always make use of quotes in such situations and probably in YAML in general, simply to make it clear, that I do wish to have the leading whitespace in the string, and it is not simply a typo, resulting from removing a former first element from the list. JSON is limitting, but for configuration I think it's kind of limitations are often good. With comments in JSON I am still not sure, because sometimes I'd like to write them there, but would not like to include another dependency, only to be able to parse away the comments from JSON. Then I better write good docs elsewhere.
user5994461 6y ago
JSON lacks comments and will fail for a missing or extra comma, so it's not great for configuration written by humans. You can use HJSON which is the json with comments. It's fully compatible with json so easy to introduce into anything that does json. https://hjson.github.io/ https://hjson.github.io/
- gsliepen 6y ago
  Failing with an extra comma also makes it harder than necessary to write JSON by machines.
- dzhiurgis 6y ago
  I'd rather take "extra comma" failure than "extra space" space failure. First one can be caught by any IDE, second one will take you a couple of minutes to find out (when building CI for example).
- westurner 6y ago
  JSON5 also supports comments and multiline strings with `\`-escaped newlines: https://json5.org/ https://json5.org/ Triple-quoted multiline strings like HJSON would be great, too.
reificator 6y ago
[<whitespace>a] could be a markdown string that begins with code.

msla 6y ago

I have an even stupider question: How do I have a key with a colon at the end? this:: right this: left Will my program be able to tell its right from its left?

pydry 6y ago

>basically YAML, "but better" That was my intention behind this, too: https://github.com/crdoconnor/strictyaml/ https://github.com/crdoconnor/strictyaml/ The general structure of YAML is fine I think but its feature set grew a little bit out of control. The "cleanliness" of the format leads to one of its inherent weaknesses - syntax can't be used to encode type information so you either need a schema to encode type information (strictyaml approach) or have magic conversions (yaml approach) or to assume strings (strictyaml w/o schema/nestedtext). The interesting thing I discovered about schemas building this is that it kind of pays to make them extensible and build them in a turing complete language. Schema validation done using a non-turing complete language (e.g. jsonschema) allows for cross language usage but it ends up being a kind of blunt object.

simonh 6y ago

> I'll start with the most basic ones (using [] as a wrapper/delimiter) So far as I can tell, this doesn’t use [ or ] in its syntax at all, so all the values you give would be represented exactly as strings without any problem.

reificator 6y ago
> So far as I can tell, this doesn’t use [ or ] in its syntax at all Yes, that's why the GP chose those characters to delimit their example strings. I'll try again using ` characters to delimit the example strings. > so all the values you give would be represented exactly as strings without any problem. But what would those string representations hold? If I parse the below strings in a javascript context, what would I get? ` a`, `a `, `"a"` and `""` Do I get this? " a", "a ", "\"a\"" and "\"\"" Or do I get this? "a", "a", "a" and "" Or do I get something inbetween?
- simonh 6y ago
  OK, I got it. I still don't see the problem. The examples include strings starting with whitespace (One of the multi-line strings), so that's not a problem. Single line strings start with the first character after the colon and a space. If that happens to be a space character, so be it. Strings are terminated by a newline, so trailing spaces aren't a problem. Quote characters are just characters with no special meaning in this format, so those aren't a problem either. Unless the library implementing this format has a bug, there shouldn't be any issues.

westurner 6y ago

From "The description of YAML in the README is inaccurate" https://github.com/KenKundert/nestedtext/issues/10 https://github.com/KenKundert/nestedtext/issues/10 : > I will mention something else. The section about the "Norway problem" is not quite accurate. Some YAML loaders do in fact load no as false. These are usually YAML 1.1 loaders. YAML 1.2's default schema is the same as JSON's (only true, false, 'null and numbers are non-strings). > Any YAML loader is free to use any schema it wants. That is, no loader is required to to load no as false. Good loaders should support multiple schemas and custom schemas. The Norway problem isn't technically a YAML problem but a schema problem. > imho, YAML's biggest failing to date is not making things like this clear enough to the community. > Note: PyYAML has a BaseLoader schema that loads all scalar values as strings.