Experiment execution

All experiments are mainly driven by two things

1. Data flow
2. User actions / User defined data

Note: Experiment shouldn't contain cycles. Repeated execution is only allowed through meta blocks.

Data flow is defined by bindings between provided variables and input ports of blocks. We should detect if user create a loop and notify him. Type check is a big problem, currently vary basic support for type checking.

If a block require user attention execution for this block are frozen, but other block cen be executed independently.

Execution supervisor (ES): is an abstract entity which control experiment execution inside th scope, notify client side, coordinate block interaction.

Each block should be able to tell its execution status at each moment. It doesn't limit a block internal state and most probably can be infered deterministically from the block internall state.

Possible execution status:

1. WORKING: block do some computation, should provide handle to access computation progress information
2. READY: input ports are bound and user provided required parameters and finished required actions.
3. DONE: block finished all internall activities. Can be reconfigured and/or runned again (we assume that all prerequisites wasn't changed).
4. USER_REQUIRED: block need user attention. Setup input ports, parameters or even fix some problem with incoming values.

Actually we can run block only if all parent blocks (w.r.t. to input ports) are also can be run or already in DONE status. Thus we cann't decided about block runnabilty solely by its internal state.

####To run an experiment: At first ES need to construct DAG of data flow inside the current scope. If ES detect cycle, such experiment can't be run at all and user shall be notified.

After, if all ES can run all blocks, it start root blocks (i.e. blocks without incoming varibles in the current scope). ES should be invoked again when started blocks are done or halt with error. Than ES can proceed execution with the further blocks or halt.