4 ms·

Thank you for your comment ! > great that you don't need quotes for keys, but why do you need quotes for values ... Quotes for string values are very importan

Thank you for your comment ! > great that you don't need quotes for keys, but why do you need quotes for values ... Quotes for string values are very important because they avoid ambiguity [1][2] and the type of quotes (single or double) tells the deserializer how to treat the string: as an ordinary string (which may have escape sequences) or a raw string. > ... is there no way to simplify data types a bit to be able to get rid of those? String values already benefit from a simplification: quotes can be placed inside a string (ordinary or raw) without a backslash to escape them. This is not the case in TOML: "Since there is no escaping, there is no way to write a single quote inside a literal string enclosed by single quotes. Luckily, TOML supports a multi-line version of literal strings that solves this problem." (https://toml.io/en/v1.0.0#string https://toml.io/en/v1.0.0#string) > for configs it's surprisingly poor with only a-z_ keys Config dictionary keys follow the identifier naming rules in C to enable mapping between config keys and variables. Therefore, one could (at least in Python) pass a config dict as arguments to functions like this: from paradict import ConfigFile def my_func(arg1=42, arg2=True, **kwargs): pass # load user_config from the 'config.dict' file path = "/path/to/config.dict" confile = ConfigFile(path) user_config = confile.get("user") # pass user_config to my_func my_func(**user_config) [1] https://news.ycombinator.com/item?id=30052128 https://news.ycombinator.com/item?id=30052128 [2] https://news.ycombinator.com/item?id=28826600 https://news.ycombinator.com/item?id=28826600

eviks 3y ago
In a huge number of cases, especially end user app config ones, not those production Norway ones, this ambiguity doesn't matter, and could be resolved through user choice of always quoting despite it being non-mandatory Re raw string - so let only it be quoted (or maybe better yet - vice versa, no quotes, no expansion), that's a valid mechanism to signal type. Just like you'd need a quote if you wanted to add whitespace are the beginning of a regular string (unless you make it only 1 space after = a valid separator) I don't get the a-z benefit in the argument case - the user must type "arg1" precisely for the argument names to match, so how does allowing Unicode make it different?
- alexrustic 3y ago
  Although most languages allow Unicode characters in identifiers, for better code portability and readability, we agree to stick to ASCII characters. Since we're already sticking to ASCII characters in our source code, I think we'll be less 'astonished' to encounter similar rules for our configuration keys (especially when a key-value pair in the Paradict configuration file looks like an instruction for variable assignment). > I don't get the a-z benefit in the argument case - the user must type "arg1" precisely for the argument names to match... Absolutely ! The user must type "arg1" precisely because this is part of the implicit agreement between the user and the system. If the user forgets to type "arg1", the default value will be taken into account. If the user adds an unexpected key (a typo for example), it will be stored in "kwargs" and then ignored or used to warn the user. I plan to build two flagship projects to leverage Paradict binary and textual formats: a lightweight database and an automation tool. The automation tool will consume a configuration file a bit like another project of mine does (https://github.com/pyrustic/backstage https://github.com/pyrustic/backstage). And this is where I join you. I think we'll both agree that since a shell command is already likely to have quotes around some of its arguments, it's very annoying to have to put extra quotes around it. So I'm thinking of introducing a Command data type: # entering 'start' in the command line will run the # unquoted string at the right side of the backtick (`) start = `program -f --flag "hello world" Backtick is used for command substitution in Bash, but is considered somewhat deprecated [1] in favor of the more modern $(command). So I think it's an interesting choice to start a Command string with a backtick. This will save us a keystroke (from two quotes, to 1 backtick !). [1] https://linuxopsys.com/topics/bash-backticks-vs-dollar-parentheses https://linuxopsys.com/topics/bash-backticks-vs-dollar-paren...
  - eviks 3y ago
    ASCII hurts readability, not helps, especially since a lot of regular text constructs that humans use to improve readability are excluded. And there is little connection with programming languages, this is a config language with a completely different profile of constraints. Also it's strange that your view of the config users is so limited as to only include programmers > If the user forgets to type "arg1", the default value will be taken into account. If the user adds an unexpected key (a typo for example), it will be stored in "kwargs" and then ignored or used to warn the user. But this is no different with nonASCII, so it's not an argument for it.

eviks 3y ago

In a huge number of cases, especially end user app config ones, not those production Norway ones, this ambiguity doesn't matter, and could be resolved through user choice of always quoting despite it being non-mandatory Re raw string - so let only it be quoted (or maybe better yet - vice versa, no quotes, no expansion), that's a valid mechanism to signal type. Just like you'd need a quote if you wanted to add whitespace are the beginning of a regular string (unless you make it only 1 space after = a valid separator) I don't get the a-z benefit in the argument case - the user must type "arg1" precisely for the argument names to match, so how does allowing Unicode make it different?

alexrustic 3y ago
Although most languages allow Unicode characters in identifiers, for better code portability and readability, we agree to stick to ASCII characters. Since we're already sticking to ASCII characters in our source code, I think we'll be less 'astonished' to encounter similar rules for our configuration keys (especially when a key-value pair in the Paradict configuration file looks like an instruction for variable assignment). > I don't get the a-z benefit in the argument case - the user must type "arg1" precisely for the argument names to match... Absolutely ! The user must type "arg1" precisely because this is part of the implicit agreement between the user and the system. If the user forgets to type "arg1", the default value will be taken into account. If the user adds an unexpected key (a typo for example), it will be stored in "kwargs" and then ignored or used to warn the user. I plan to build two flagship projects to leverage Paradict binary and textual formats: a lightweight database and an automation tool. The automation tool will consume a configuration file a bit like another project of mine does (https://github.com/pyrustic/backstage https://github.com/pyrustic/backstage). And this is where I join you. I think we'll both agree that since a shell command is already likely to have quotes around some of its arguments, it's very annoying to have to put extra quotes around it. So I'm thinking of introducing a Command data type: # entering 'start' in the command line will run the # unquoted string at the right side of the backtick (`) start = `program -f --flag "hello world" Backtick is used for command substitution in Bash, but is considered somewhat deprecated [1] in favor of the more modern $(command). So I think it's an interesting choice to start a Command string with a backtick. This will save us a keystroke (from two quotes, to 1 backtick !). [1] https://linuxopsys.com/topics/bash-backticks-vs-dollar-parentheses https://linuxopsys.com/topics/bash-backticks-vs-dollar-paren...
- eviks 3y ago
  ASCII hurts readability, not helps, especially since a lot of regular text constructs that humans use to improve readability are excluded. And there is little connection with programming languages, this is a config language with a completely different profile of constraints. Also it's strange that your view of the config users is so limited as to only include programmers > If the user forgets to type "arg1", the default value will be taken into account. If the user adds an unexpected key (a typo for example), it will be stored in "kwargs" and then ignored or used to warn the user. But this is no different with nonASCII, so it's not an argument for it.