Unfortunately external configuration is much more than just serialisation. For me, an ideal universal configuraion library will provide schemas, type checking,

Unfortunately external configuration is much more than just serialisation. For me, an ideal universal configuraion library will provide schemas, type checking, full structural validation, and externalised defaults so I can tell the difference between a value explicitly set (or reset) to the default by the user, and a value that has never actually been changed. Hardcoded defaults are evil, configuration is actually a stack of developer-set defaults, packager/distro set defaults, sysadmin-set defaults and user preferences. Imho these are much more tiresome problems than serialisation imho. If I were going to build a configuration library I'd probably use Apache Avro[1] as a base. It has a lot of these ingredients already. For parsing atm, since I write mostly C++, I'm prone to just using Boost Property Tree[2], which exploits the fact that most of these formats (even XML) are just trees of key-value pairs. There are parsers for XML, JSON, INI and INFO formats[3] With regard to this project, it'd be nice if the author would write a complete grammar for his UCL format. The advantage of JSON is it's really well documented[1] and I can always go and grab another implementation. There's nothing in this repo except the hand-written C code. Other than that, the cleanups to the syntax look nice and friendly. [0] https://avro.apache.org/docs/current/ https://avro.apache.org/docs/current/ [1] http://www.json.org/ http://www.json.org/ [2] http://www.boost.org/doc/libs/1_55_0/doc/html/property_tree.html http://www.boost.org/doc/libs/1_55_0/doc/html/property_tree.... [3] http://www.boost.org/doc/libs/1_55_0/doc/html/boost_propertytree/parsers.html http://www.boost.org/doc/libs/1_55_0/doc/html/boost_property...