We've had lots of people say 'yuck' when they find that they have to generate java code in order to write a connector to a data source like mongo.
Current MongoToEnumerableConverter is like 100 lines long.
It does not look like a "yuck".
Well, it does, however the major part of the mongo code is "passing non literal ArrayList to linq4j".
"generate java code" part is not more than "tell Calcite to execute MongoTable.aggregate(...)".
We never suggested moving all the code to linq4j part. On contrary, the idea was to use as little linq4j as it is possible and to upcall to the java.
The "problem" can easily be solved if something like EnumerableRelImplementor.result(Bindable impl, PhysType) is added.
If non-numeric, non-string literals were allowed in linq4j, then mongo code would be just "Expressions.call(MONGO_QUERYABLE_AGGREGATE)}}" kind of thing with no other "code generation" stuff.
It still makes sense to allow "passing of non-literal constant values to linq4j" to simplify the life of those who do generate code.
So the mongo-to-enumerable adapter could go without any notion of Expression/Expressions/BlockBuilder/etc.
Do you still think it worths reimplmenting the wheel just for that?
By the way, another nice thing about a true relational interpreter is that you could envisage building a debugger on top of it,
The nice part of generation of java code is you can have the generated code in the bug reports.
Lots of people know how to read java, so it simplifies the analysis.
Having step-by-step debugging is a nice feature, however I belive IDE's can be tricked to step-by-step through the generated code.
By the way: when I was implementing window functions support, I copied and pasted the generated code and debugged it in the IDEA from times to times.