Create reverseValue mappings for all expressions from core.expr.base

[arimer]

Currently we have no reverseValue mappings for interpreted expression concepts from the core.expr.base language.

It should be possible to retrieve an expression node from the Java object, which resulted from the interpreter execution.

Example: node<NoneLiteral> -----> new NoneValue() is defined noneValueObject -----> node<NoneLiteral> is missing

[coolya]

Would be good to know why this is required.

[arimer]

@wsafonov could you scatch a short scenario where this is needed?

[wsafonov]

So we currently have support for reverse mapping of numbers, but in case we have any computation result that yields a NoneLiteral object, we would need to translate it back to the expression node. In case tracing back to the original node would work here, it would be fine. But I'm not sure how that feature works and what would be the constraints (e.g. what if some object would be a result of some computation, but not 1:1 mapping of the original expression node?)

[markusvoelter]

Supporting reverse mapping for all expressions is not feasible. If this was really needed, one would instead implement the interpreter in a way where the execution domain is also KernelF. That's a big rewrite. Adding a few additional reverse mappings, for example for none, is another matter, I think this makes sense.

[coolya]

@wsafonov I still don't know why you need the reverse mapping? What is your use case for them? Is this for the instance tree? Why would the normal trace from the interpreter fulfil you requirements?

[wsafonov]

@coolya yes, we need it in the instance tree generation in order to fill the values of the computed attributes and parameters in the generated tree. I'm not quite sure that having a backtrace to an expression would be always possible. Think of this maybe somewhat artificial but potentially imaginable example: we have an expression that queries a collection with findFirst() operation that returns NoneValue() object in the evaluator because no matching value was found. In this case I wouldn't have a trace to a NoneLiteral expression, because it simply doesn't exist in the original model and the interpreter computes NoneValue() directly and only if input data of the evaluated expression fulfills specific condition.

[arimer]

@wsafonov is this ticket still required in any way or can we just close it? To my knowledge instance tree impl. was done on iests3.core.