Similar to integer, there is an expression type in the specification to have callback functions for map, reduce, sortBy, register.
Since an expression should always return a JSON type and, based on the grammar, you can only have an expression reference as a function parameter, expression is not a first-class type and can only be a literal argument in one of these functions. So my assumption is that you cannot coerce from/to expression in any way and any time you pass it into a non-expression parameter, it should throw a type error.
This has not been the case in the implementations and it seems like internals are leaking a bit... Here is a CSV with the failed expression tests: test-results.expression.csv.
The type(&42) one is a bit debatable, as, based on the specification, it should throw a type error as well and there is little point in getting a type of the literal. But for consistency sake I made it return "expression" instead, based on how it is named in the doc.
On the same point, with the expression in the mix of parameter types, any is a bit of an unfortunate name, as it doesn't include expression. Maybe rename any to json instead to avoid potential confusion? So in that case above type will have a json | expression parameter.
These are findings from running this test suite, which is a bit opinionated right now, but covers the expression case as written here.
Similar to
integer, there is anexpressiontype in the specification to have callback functions formap,reduce,sortBy,register.Since an expression should always return a JSON type and, based on the grammar, you can only have an expression reference as a function parameter,
expressionis not a first-class type and can only be a literal argument in one of these functions. So my assumption is that you cannot coerce from/toexpressionin any way and any time you pass it into a non-expression parameter, it should throw a type error.This has not been the case in the implementations and it seems like internals are leaking a bit... Here is a CSV with the failed expression tests: test-results.expression.csv.
The
type(&42)one is a bit debatable, as, based on the specification, it should throw a type error as well and there is little point in getting a type of the literal. But for consistency sake I made it return "expression" instead, based on how it is named in the doc.On the same point, with the
expressionin the mix of parameter types,anyis a bit of an unfortunate name, as it doesn't includeexpression. Maybe renameanytojsoninstead to avoid potential confusion? So in that case abovetypewill have ajson | expressionparameter.These are findings from running this test suite, which is a bit opinionated right now, but covers the expression case as written here.