If you're thinking about implementing this or something like this, please stop. Unless you're writing in a compiled language, use the same language your applic

If you're thinking about implementing this or something like this, please stop. Unless you're writing in a compiled language, use the same language your application is written in for your configuration. If you have a python application, have a python file for the configuration. Same for ruby or whatnot. You don't need to use the entire language, but at least use the language's lexer/parser (cf. json/javascript). That way, all existing tooling for the language will work for the config files (ask me about how saltstack happily breaks their API because you're not "supposed" to use it, despite the fact that they have public docs for it). Additionally, people won't need to figure out all the stupid corner cases in your weird language that has no uses outside of a few projects. Additionally, by making your configuration language an actual language, you also simplify a lot of the system design, because the configuration can act directly against your API. This means using your tool from other tools becomes much more straightforward, because the only interface you actually need is the API. The existence of "configuration language" is, itself, a mistake.