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 anexpression
type 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,
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/toexpression
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 includeexpression
. Maybe renameany
tojson
instead to avoid potential confusion? So in that case abovetype
will have ajson | 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.