[linkdd]

Expressions that will be evaluated at runtime are just strings, no?

  {"rules": [
    "x > 1",
    "x % 2 = 1"
  ]}

So you will have an "expression parser" to parser your rules, validate them, and execute them. But at least you do not have the edge cases of everything else.

[_gabe_]

At this point you're already writing your own parser to parse the expressions from the strings. Why not cut out the json completely and make it way more readable?

  rules = [
    x + 1,
    x % 2 == 1
  ]

[giaour]

Those are simple expressions (no multiline blocks, no named symbols, no expressions that call other expressions), and you're still forced to treat them as opaque strings when you use a serialization language for configuration.

That may be the best approach for a given project! But if you're using configuration to define an API contract, cloud infrastructure, or a query, you might be better off using a purpose-built DSL like protocol buffers, HCL, or SQL, respectively. That approach can let you define a greater level of expressivity than is allowed in a serialization language like JSON or XML without letting config authors write scripts of arbitrary computational complexity (like they would be able to with config in a scripting language).

[kevin_thibedeau]

This sort of hack with control logic was done in XML with Ant. It was a bad idea then and it still is.