[lmm]

> it can impose as many restrictions as it wants on what expressions are allowed

Sure, but it's very easy to accidentally be Turing complete. You added loops? Boom. You added some kind of alias / extract-common-value feature? Boom. Etc.. Of course you can forcibly restrict the implementation (I wrote a Y combinator in one of them and found that the interpreter would detect recursion at runtime and refuse to process it) but at that point you're making your language inconsistent which is even worse.

> protocol buffers, GraphQL schema language, Thrift IDL, Avro IDL, Smithy

Those aren't "rules engine"s though. Once you get to the point of having expressions in your language, you slide down the slippery slope pretty quickly, IME.

[giaour]

> Those aren't "rules engine"s though

Yeah, I don't know why I picked rules engines as an example of things that are hard to configure with JSON. My day job is working on an infrastructure-as-code DSL, and I previously worked on an RPC framework IDL. Both of those projects are replacing an alternative in a traditional serialization language (JSON and XML, respectively) where users spent a lot of their time fighting against JSON or XML gotchas.

The IaC language supports expressions but not named expressions, so we've been able to avoid Turing completeness so far.

[lmm]

That may not be enough; you wouldn't be the first supposedly-non-Turing-complete language where it's actually possible to express a Y combinator and use that to embed arbitrary computations.