I like JMESPath, but it has some serious limitations which prevent it from being as general purpose as jq.<p>JMESPath limitations:<p>- No simple if/else, but it is possible using a hack, documented below.<p>- The to_number function doesn't support boolean values, but it is possible using a hack, documented below.<p>- can't reference parents when doing iteration. Why? All options for iteration, [* ] and map, all use the iterated item as the context for any expression. There's no opportunity to get any other values in. May be possible for a fixed set of lengths. Something akin to the following (except there is no syntax for switching or if statements):<p><pre><code> switch (length):
case 1: [expression[0]]
case 2: [expression[1], expression[1]]
case 3: [expression[0], expression[1], expression[2]]
...
</code></pre>
- Key name can't come from an expression. Why? The ABNF for constructing key-value pairs is given as: keyval-expr = identifier ":" expression. The key is an identifier, which gives no possibility for making it an expression. No functions modify keys in such a way as to allow using an expression as a key.)<p>- No basic math operations, add, multiply, divide, mod, etc. Why? Nobody added those operators/functions.<p>- There's a join, but no split.<p>- No array indexing based on expression. Why? Indexing is done based on a number or a slice expression, which also doesn't support expressions. Here's the ABNF:<p><pre><code> bracket-specifier = "[" (number / "* " / slice-expression) "]" / "[]"
</code></pre>
- No ability to group_by an expression.<p>- No ability to get the index of an element in a list<p>Hacks:<p>Convert true/false to number:<p><pre><code> boolean_expression && `1` || `0`
</code></pre>
If/else:<p>Option 1)<p><pre><code> [{q:CONDITIONAL_EXPRESSION, v:IF_RESULT_EXPRESSION},{q:!COND_EXPRESSION,v:ELSE_RESULT_EXPRESSION}][?q]|[0].v
</code></pre>
Option 2)<p><pre><code> {"if":CONDITIONAL_EXPRESSION, "ctx":@} | [{q:if ,v:ctx.IF_EXPRESSION},{q:!if,v:ctx.ELSE_EXPRESSION}][?q]|[0].v</code></pre>