New architecture for code generation in expressions.

[Eike]

Currently during the evaluation of expressions, the built in functions raise an exception when code should be generated. This creates problems with the idea that compilation is really interpretation of the program with code generation as a side effect. (Bug #597234 )

 * A possible idea is to return unknown values instead of unevaluated expressions.
* A possible idea is to return unknown values instead of raising an exception.
     * The function generates an assignment statement. Its RHS contains the call to the elementary function, its LHS an unknown intermediate value.
     * The intermediate value could be directly optimized away by the expression code.
* The value would be directly optimized away by the expression code.
     * It would make elementary functions that return objects of multiple types possible; but are those functions desired?
* It would make functions that return objects of multiple types possible; but are those
  functions desired?

Problems:
 * Functions with side effects, and that return NONE must have a way to request that code is generated.
* Functions that return NONE must have a way to request that code is generated.

 * Assignments must be performed differently (they can't return an unknown value), but they are performed differently currently too.
* Assignments must be performed differently (they can't return an unknown value), but they
  are performed differently currently too.

See also:

 * Bug #597234 - Interpreter.eval_NodeAttrAccess must be able to look up attributes of unevaluated
  expressions.
 * NewCodeGenerationArchitecture

https://sourceforge.net/apps/trac/freeode/ticket/40