| 2010-11-07 18:33:08 |
Eike |
bug |
|
|
added bug |
| 2010-11-07 18:33:22 |
Eike |
freeode: importance |
Undecided |
Wishlist |
|
| 2010-11-07 18:35:49 |
Eike |
tags |
|
code-generator expression interpreter |
|
| 2011-06-10 22:34:10 |
Eike |
description |
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 raising an exception.
* The value would be directly optimized away by the expression code.
* It would make functions that return objects of multiple types possible; but are those
functions desired?
Problems:
* 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.
See also:
Bug #597234 |
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 raising an exception.
* The value would be directly optimized away by the expression code.
* It would make functions that return objects of multiple types possible; but are those
functions desired?
Problems:
* 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.
See also:
Bug #597234
https://sourceforge.net/apps/trac/freeode/ticket/40 |
|
| 2012-02-02 23:32:34 |
Eike |
freeode: status |
New |
Confirmed |
|
| 2012-02-29 20:49:34 |
Eike |
description |
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 raising an exception.
* The value would be directly optimized away by the expression code.
* It would make functions that return objects of multiple types possible; but are those
functions desired?
Problems:
* 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.
See also:
Bug #597234
https://sourceforge.net/apps/trac/freeode/ticket/40 |
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 #7 )
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
* Bug #7 - Interpreter.eval_NodeAttrAccess must be able to look up attributes of unevaluated expressions.
* NewCodeGenerationArchitecture
https://sourceforge.net/apps/trac/freeode/ticket/40 |
|
| 2012-02-29 22:31:27 |
Eike |
freeode: milestone |
|
0.4.2 |
|
| 2012-04-03 08:24:44 |
Eike |
description |
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 #7 )
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
* Bug #7 - Interpreter.eval_NodeAttrAccess must be able to look up attributes of unevaluated expressions.
* NewCodeGenerationArchitecture
https://sourceforge.net/apps/trac/freeode/ticket/40 |
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 #7@lp )
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 )
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 )
interpretation of the program with code generation as a side effect. (Bug #597234@trac )
* 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
Bug #597234@trac
* Bug #7@lp - Interpreter.eval_NodeAttrAccess must be able to look up attributes of unevaluated expressions.
* Bug #597234 - Interpreter.eval_NodeAttrAccess must be able to look up attributes of unevaluated expressions.
* NewCodeGenerationArchitecture
https://sourceforge.net/apps/trac/freeode/ticket/40 |
|
| 2012-04-03 08:59:30 |
Eike |
description |
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 #7@lp )
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 )
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 )
interpretation of the program with code generation as a side effect. (Bug #597234@trac )
* 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
Bug #597234@trac
* Bug #7@lp - Interpreter.eval_NodeAttrAccess must be able to look up attributes of unevaluated expressions.
* Bug #597234 - Interpreter.eval_NodeAttrAccess must be able to look up attributes of unevaluated expressions.
* NewCodeGenerationArchitecture
https://sourceforge.net/apps/trac/freeode/ticket/40 |
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 |
|
