[qvtd-dev] Evaluator / Executor evolution

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

I have completed the main part of the enhancement of the QVTi 
interpreter to support
- Model::objectsOfKind() rather than allInstances()
- MappingCall::isInfinite to detect and avoid infinite recursion
- MappingCallBinding::isPolled to detect and defer mapping executions 
until their reads are successful

Behind the scenes the support maintains a partial or full 
EvaluationStatus model that is dumped as a graphml file by the unit tests.

The extra support is currently realized by using QVTiIncrementalExecutor 
rather than its BasicQVTiExecutor superclass. The mode can be set to 
LAZY which creates EvaluationStatus instances only where necessary. 
INCREMENTAL creates them always in preparation for a yet to be 
implemented REPAIR execution. I'll probably fold the 
QVTiIncrementalExecutor into the BasicQVTiExecutor which has very 
limited use by itself (only useful if all mappings are polling/recursion 
free.)

Executor replaces Evaluator which was badly designed. The old Evaluator 
was implemented by the EvaluationVisitors and consequently invocation of 
a Mapping required not only creation of a nested EvaluationEnvironment 
for the nested state but also a nested EvaluationVisitor and all its 
Debugging/Tracing decorators. This was messy in the debugger and 
unhelpful for the new incremental support. Evaluator is therefore split 
in two. EvaluationVisitor provides the 'stateless' visiting stretegy and 
may be decorated as before. Executor provides the execution 
supervision.  There is no need for nested Executors or nested 
EvaluationVisitors; much simpler. Quite a bit more of the QVTi debugger 
code is now reafctored and shared with the OCL debugger.

Splitting the Evaluator is not easy while keeping API tooling happy, but 
with the aid of too many xxxExtension interfaces it can be done and so 
we can defer the need for an OCL major version change until the OCL 2.5 
impact is apparent. (Unfortunately although many packages were named 
'internal', they were not declared as such in the MANIFEST and so API 
tooling complains about all internal changes.)

This code is all available in the OCL/QVTd ewillink/463313 branches. 
I'll push to master once Mars is final and I've checked for more API 
creep to support the CGed execution.

Migration. Evaluator => Executor. For QVTi there is no API preservation 
issue so make sure you use an Executor to avoid needing to rediscover 
it. Within OCL, either ValueUtil.getExecutor(evaluator) or an 
evaluator.getExecutor() may work, possibly aided by a cast to an 
XXXExtension.

    Regards

        Ed Willink