3 ms·

Although most languages allow Unicode characters in identifiers, for better code portability and readability, we agree to stick to ASCII characters. Since we're

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.
- alexrustic 3y ago
  Thank you for your comment ! This issue consumed a lot of my brain thinking cycles, which is why Textual Paradict allows both of its modes (data and config) to be used in the same document or section: [user] name = 'John Doe' 'région': 'Himalaya' > ASCII hurts readability, not helps, especially since a lot of regular text constructs that humans use to improve readability are excluded. Characters like œ [1] or ï [2] are common in my everyday vocabulary, but I've always stuck to ASCII and underscore in my code sources for reasons like keyboard layout availability, portability, IT legacy, etc. > Also it's strange that your view of the config users is so limited as to only include programmers The Paradict texual format has two modes (data and config) for this very reason: we need a relaxed version of the data mode. I will continue to weigh the cons and pros for the characters allowed in the config keys. At the moment, some of the pros are: - Developer experience: the 'dictionary unpacking' [3][4][5] capability in programming languages is really cool. - Target population: I assume that the majority of configfile users are programmers and those who are not are used to following more complicated rules (e.g. formulas in spreadsheets). - Least astonishment principle: people already know by heart the rules for naming identifiers in C (which inspired many other languages). - The "key = value" syntax is the same as the variable assignment syntax. - With rendering ASCII as a monospaced font, we won't complain about a character being visually similar to a space or the equal sign (=). [1] https://en.wikipedia.org/wiki/%C5%92 https://en.wikipedia.org/wiki/%C5%92 [2] https://en.wikipedia.org/wiki/%C3%8F https://en.wikipedia.org/wiki/%C3%8F [3] https://reference.codeproject.com/python3/dictionaries/python-dictionary-unpack https://reference.codeproject.com/python3/dictionaries/pytho... [4] https://discuss.python.org/t/syntax-for-dictionnary-unpacking-to-variables/18718 https://discuss.python.org/t/syntax-for-dictionnary-unpackin... [5] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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.

alexrustic 3y ago
Thank you for your comment ! This issue consumed a lot of my brain thinking cycles, which is why Textual Paradict allows both of its modes (data and config) to be used in the same document or section: [user] name = 'John Doe' 'région': 'Himalaya' > ASCII hurts readability, not helps, especially since a lot of regular text constructs that humans use to improve readability are excluded. Characters like œ [1] or ï [2] are common in my everyday vocabulary, but I've always stuck to ASCII and underscore in my code sources for reasons like keyboard layout availability, portability, IT legacy, etc. > Also it's strange that your view of the config users is so limited as to only include programmers The Paradict texual format has two modes (data and config) for this very reason: we need a relaxed version of the data mode. I will continue to weigh the cons and pros for the characters allowed in the config keys. At the moment, some of the pros are: - Developer experience: the 'dictionary unpacking' [3][4][5] capability in programming languages is really cool. - Target population: I assume that the majority of configfile users are programmers and those who are not are used to following more complicated rules (e.g. formulas in spreadsheets). - Least astonishment principle: people already know by heart the rules for naming identifiers in C (which inspired many other languages). - The "key = value" syntax is the same as the variable assignment syntax. - With rendering ASCII as a monospaced font, we won't complain about a character being visually similar to a space or the equal sign (=). [1] https://en.wikipedia.org/wiki/%C5%92 https://en.wikipedia.org/wiki/%C5%92 [2] https://en.wikipedia.org/wiki/%C3%8F https://en.wikipedia.org/wiki/%C3%8F [3] https://reference.codeproject.com/python3/dictionaries/python-dictionary-unpack https://reference.codeproject.com/python3/dictionaries/pytho... [4] https://discuss.python.org/t/syntax-for-dictionnary-unpacking-to-variables/18718 https://discuss.python.org/t/syntax-for-dictionnary-unpackin... [5] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...