Wladimir Safonov

> I would prefer if we would have different solutions for all the different apache commons libs. It is not a lot of overhead and makes it more obvious what...

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...

@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...

Looks good to me, just one question: why did you remove and readd the `InlineAll` intention under `inlineAll2` name?

> Because there was a problem with this intention - so it looked. In my desparation, I reimplemented it. But the problem was a different one. Does it make sense...

> maybe a bug in the TS: shouldn't be type number also be of type any testsuite AlgebraicLanguage::eval() To me `any` seems to be a candidate to be a supertype...

Not quite sure what generator you are talking about. In case you have you own custom type, you would need to implement your own generator for all operations that support...

Ok, maybe I've misinterpreted your request. So currently the java generator is not built with an available easy replacement option for java runtime types. That means for IntegerType for example...

It's not enough just to encapsulate creation of java objects behind some pluggable factory method. Think about all other code to be generated that has to deal with numbers. If...

`org.iets3.core.expr.data` and `org.iets3.core.expr.lookup` should be better left in **advanced** (being already used in a customer project)