Well, dynamic queries by end users is the main goal here. Your static
helper functions are completely unusable in that context. Analysing a
query and generating code at runtime is easy and idiomatic with
uniform syntax (and accompanying language support) and the claim is
that solution is not only speedier but implementation in CL is
qualitatively simpler than the alternatives.
The point my first comment made is that you don't need to analyse a query at runtime, you just need to provide functions. I will agree again that Lisp makes REPLs easier to write than does C++, but a CL with Lua syntax could still, just as easily, provide functions and expose a REPL. It's the same solution, just without the unjustified AST transformations.
How can you provide a REPL language without analyzing it at runtime?
Write Lua random syntax in the REPL? Not a great improvement over
C++. Not to mention that you'll probably use something like `eval`
which is not compilation thus inferior.
By the way, even your original example - I can't see how it can work
honestly. How can you identify fields through (lambda) parameter names
only (no mention of types either)? Probably the least
boilerplate-heavy solution would be stringly typed.
> something like `eval` which is not compilation thus inferior
I honestly don't know what that means. Turning text into code is compilation; there is no difference between the two in that regard, except perhaps that in the Lisp DSL case it's more manual.
> How can you identify fields through (lambda) parameter names only (no mention of types either)?
Not familiar enough with Lua, but in Python you just use keyword arguments.
