Challenge: four interpreters, one principle

The previous five lessons taught four concrete interpreters: SQL, the ORM, HTML, a shell, XML. This lesson tests something else: whether you recognise an interpreter no lesson taught you.

Because at work the sixth interpreter always turns up — a template engine, an expression library, a rules runner, an LDAP query, a log format string. No list covers them all, so the thing worth learning is how to recognise one.

Three questions, and they suffice for every interpreter you will meet:

1. Does this data reach something that will parse it? If it is only stored or compared, it is not injection.
2. Is there a protocol-level boundary between command and data? Yes → parameterise. No → you must build the boundary yourself, usually with an allow-list.
3. Does the data ever become syntax rather than a value? If so, no API can parameterise it — it needs mapping to a constant.

What to produce. Four snippets, four interpreters, at least one absent from the previous five lessons. For each: name the interpreter, state the correct fix, and say why the fix for a different interpreter does not work here. The third part is what counts.