Compile Statement: Parameterize and Split into Reusable Steps

Registered by Eike on 2010-05-13

The code for the compile statement, and the checking and flow graph building, are a big mess. This code should be split up into reusable components, so that different types of simulations can be performed: ODE/PDE solving, minimum finding, describing a complicated function with computation of derivatives.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Medium
Drafter:
None
Direction:
Approved
Assignee:
None
Definition:
Discussion
Series goal:
Accepted for trunk
Implementation:
Not started
Milestone target:
milestone icon 0.4.1

Related branches

Sprints

Whiteboard

Structuring into different objects:
- CompilerDriver: contains methods that parameterize the interpreter for compilation.
- CodeCollector: contains code collection methods and data that are currently in the interpreter.
    - This collides with the idea to see the generated statements as the function's return value.

Structuring into different methods:
- Functions that direct the compilation for each (type of) main function (for example:
  "compile_dynamic", "compile_init", ...)
    - Find the main functions in the simulation object.
    - Create the empty compiled function, create additional input values if necessary (init_* functions).
    - Call the main function (init_* functions).
    - ???

Parameters for customization:
- Base class of generated Python class.
- Which methods are the main methods
- Signatures of the main methods
- Which roles are legal for assignment

General ideas:
- Convert compile statement into compile function. The function arguments would provide the mini language to specify
  options.
    - Compile function could be written in Siml, and call several built in compilation functions. This would make
      cusomization of the compilation algorithm quite easy for advanced users. They could write their own compilation
      functions.
- Perform data creation step through implementation of data statement
See blueprint for improved data statement:
https://blueprints.launchpad.net/freeode/+spec/data-statement

- Automatic calling of main functions in child objects. No longer writing "system.dynamic()" everywhere.

Data:
The flattened methods should have a structure that already reflects the compiled code:
- code
- input variables
- output variables
- intermediate variables
- state (parameters)

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.