There are several things which have to be decided for something as simple as equality comparison. I have no idea how hard or easy it would be to implement it in any form for Pandoc templates, but will point to some decisions which might need to be made.

Pandoc variables/metadata can be of several types: strings, booleans, complex data structures — lists and key—value mappings which in turn can contain any type. I’m not sure if Pandoc treats numbers as distinct from strings; metadata seems not to. This raises several questions: What happens when the compared objects are of different types: are they silently unequal or is there a warning or an error? How do complex data types compare to each other: content or object equality, same keys or also same values, or same number of keys for mappings? Same items or same number of items for lists? You probably end up needing a length operator!

If there are going to be size comparison (less/greater (or equal)) how is size determined. I touched on that above for complex data types, but there are problems for strings too: do we compare byte length or (UTF-8) character length? (I hope the latter!) I don’t know to what extent metadata contains AST-like objects at the template processing stage, but if they do how do they compare: similar to complex data data structures and/or text content equality? If both there may be need for an operator which stringifies its operand. Shall it be possible to regex match strings?

It may be possible to mimic the way Pandoc’s Lua API does these things, perhaps even possible to reuse code but pretty soon you will start to have features similar to a general programming language. Where do you draw the line? You could even allow embedding for example Lua, but that may clash with more core templating features, there may be security concerns, and how do you pass what to Lua-land?

I have thought a lot about this kind of thing, having put quite some work into creating a small template-like (pre)processor — I call it an interpolation engine because it can’t really handle formatting of multi-line blocks. Two things which I needed to decide were whether to support complex data structures and whether it should be possible to assign values to variables. For now the answer is yes to the first — with the limitation that you can only compare string and/or number xor boolean leaf values — and no to the second. In core only comparison, pattern matching and true/false — Lua style where only `false` and `nil` evaluate as false — or empty/nonempty — empty string and 0 also evaluate as false — boolean evaluation with something like a ternary operator syntax is in core but there is extensibility by letting the program using the engine supply functions to do arbitrary things, with a syntax for calling and passing arguments to such functions. There is also a mechanism for inserting characters by codepoint or entity name. The thing is that even with comparison etc. built in from scratch and with the limitations on what can be compared a lot of decisions and different operators had to be made. I ended up with several things which made the language not-so-small anymore:

-   Distinct logic operators for if-true/if-false and if-non-empty/if-empty (they are modular `??` vs. `?!` and `&?` vs. `&!` but anyway!

-   Distinct operators for numeric (e.g. `==#`) and case-folded (e.g. `==?`) comparison in addition to straight string comparison (e.g. `==`). Added complication: there is (of course) no numeric pattern matching, but the parser has to take special note of attempts to use the would-be operator!

-   Distinct “text” — parenthesis delimited, with interpolation — and “string” — quotes delimited without interpolation.

-   Distinct string-variable/function/character-by-id/math interpolation syntaxes (and math is basically an additional DSL which isn’t fully implemented yet!)

-   Distinct string and math variable spaces.

-   Support methods for doing expansion-like things with function arguments.

-   There are all of for/while/until style loops (although limited to the kinds of comparisons described above).

The outcome: I have switched to a simpler syntax which basically is sprintf on not quite as much steroids:

(1) Arguments are specified as variable names inside the string.

(2) Custom conversions implemented as functions passed when instantiating the formatter object.

(3) Custom conversions can have almost arbitrary names, including multi-character names.

(4) Multiple arguments per format specifier are possible:

    (a) by default this means “use the value of the first existing variable corresponding to a name in the argument list”, but

    (b) custom conversions can use the arguments (all strings) however they please, including using them as embedded format strings.

Nothing more, but (2), (3) and (4)(b) make a wide variety of extensibility possible — including everything the more complex syntax described above does —, so inevitably I wrote a “micro” implementation which leaves any non-standard argument parsing to custom conversion functions and in core supports only single variable name arguments and standard sprintf conversions.

/bpj