5 ms·
So if my understanding is correct, the RethinkDB driver translates a Python function object into its "abstract interpretation" by invoking the function on a pro
by ot 13y ago
So if my understanding is correct, the RethinkDB driver translates a Python function object into its "abstract interpretation" by invoking the function on a proxy object x that defines operators such that (simplifying) x.__op__() returns Op(x). Recursively, this yields the computation tree of the function. This looks very similar to what is done in C++ metaprogramming through "expression templates", a technique that is taken to its extremes in libraries such as Boost.Proto. C# solves this more cleanly by having in the language an explicit concept of "expression trees" that are given as arguments of LINQ queries.
I wonder if this imposes any limitations on the functions that can be written. For example, how are if, for statements handled? What happens if I do "lambda x: y + x" where "y" is an object that defines __add__? If these cases are not handled, is a well-defined exception raised?
- coffeemug 13y agoThis is tricky and there are certainly limitations. For example, you can't translate an if statement, so instead we implement our own branch command (http://rethinkdb.com/api/#rb:control_structures-branch http://rethinkdb.com/api/#rb:control_structures-branch) We overload operators when we can (unfortunately no operator overloading for Javascript folks) and it works really well. You don't always get a great exception, but most of the time this turns out to be fine. Novices don't need to worry about this too much, and we found that as people get more into ReQL, they pick everything up extremely quickly, and they rarely confuse things or make mistakes.
- hosay123 13y agoThere are two alternatives to what RethinkDB does: parsing the function's associated source file (yucky and breaky when multiple lambdas per line) or disassembling its func_code.. I've looked at this problem before (and ran away screaming every time), but the approach I tended towards was func_code disassembly, pretty much for the reasons you mention. Was this ever considered?
- coffeemug 13y agoWe did look into disassembly, but decided that it's far too much work because it is not portable across languages and drivers, and would require an enormous engineering effort (both for ourselves and for community driver maintainers). From a purely theoretical POV, I do like the idea of disassembly better, but unfortunately we couldn't make this work and remain pragmatic.
- apendleton 13y agoI wonder if, for "if," you could just detect that your magical variable was being cast to a boolean, and run the function twice, once where it returns true, and once false, so you could exercise both branches. I guess this could get a little pathological if you had multiple conditionals and their nesting was really complicated, but I bet you could do simple conditionals...