Higher order UDFs would indeed be awesome! You’ve shared an excellent use case – passing lambdas to Map, Reduce, and Filter functions.
Workaround with pre-defined UDFs
A workaround for passing eval-able lambdas into other functions is to use pre-define UDFs instead. This restricts users from selecting from a limited set of functions, rather the full breadth of FQL. But if you need the latter, you might consider letting users have access to resources to make their own queries anyway (As opposed to only exposing a few UDFs).
UDFs are referenced by their name, so instead of a filter_lambda parameter you can have a filter_udf_nameparameter, and use it like this:
// ...
Filter(
Var("match_set"),
Lambda("values", Call(Var("filter_udf_name"), Var("values")))
)
// ...
other use cases
It’s come up some other times that I am aware of in the forums. Higher order functions could help solve some other known problems like reusing Role predicates, or creating new functions that close over provided values.
One workaround for defining new UDFs is to store configurable values in the data of the new UDF, rather than provide a lambda.