Hypothesis

If we allow a limited set of reentrant functions in the evaluator, it will be possible to increase reliance on evaluated implementations, thereby leveraging the most performant part of the backend.

Reasoning

• It is often possible to rewrite a composition implementation as an evaluated implementation (i.e., using JS or Python), with marked improvements in performance and stability. However, sometimes, the most natural way to express a function involves retrieving a Wikidata item (or some other entity) in the middle of a function call; at other times, this kind of extemporaneous resolution is not only natural but essential, e.g. when the entity to be retrieved depends on the function's input. Such retrievals are not possible at present. For these cases, we need some reentrancy–i.e., the ability for the evaluator to make calls back to the orchestrator.
• The inability to call a function from an evaluated implementation is a “function creation pain point”, which has been recognized for some time.
• By starting with a limited set of reentrant functions, we will gain learnings that can set the stage for subsequently supporting a broader set of reentrant functions.

Acceptance Criteria

• Reentrant calls work reliably for functions that retrieve Wikidata entities and ZObjects, and other functions we decide to include in this capability (if any).
• An implementation that retrieves an object using reentrancy is no slower than one in which the retrieval call is done in a composition.
• Reentrant calls are clearly documented and usable by community members.

Success Metrics

• Successful creation of evaluated implementations employing the new capability.

Dependencies
SRE approval of architectural elements of the approach; configuration changes (if needed) to enable orchestrator-evaluator Web socket connection.