Curious how much work is involved in improving the parser's handling of symbols in unquoted strings

[mikehearn]

trafficstars

I realize this library is unmaintained so this is more a query in case anyone knows how much work is involved, or what issues I might hit.

My app involves a lot of config values that contain symbols like = and :. HOCON can handle this but requires string quoting. Not a big deal in the grand scheme of things, but, it does mean you have to remember to quote stuff except when using interpolation, which looks weird/ugly and is easy to forget if you aren't using an IDE. I'd really like either:

1. Substitutions to be evaluated inside string values when that makes sense.

or

2. For the parser to be OK with more symbols appearing in values.

I assume the rule that you can't have unquoted : or = is because otherwise it'd be ambiguous with another key/value pair. I'm wondering if that rule can't be worked around in some way. a = --b=c or url = https://foo/bar isn't ambiguous to a human.

[havocp]

You could certainly try; I think it will be pretty challenging to do in a backward-compatible way but if you don't care about that maybe it can be done. The trick to back compat would be to find some cases that are always errors now and only make those newly-allowed; if you change the meaning of things that aren't errors now of course it won't be compatible.