Automatic loops

This page discusses the possibility or getting rid of the awkward controlflow-style looping. We could allow modules to automatically loop if a module's port gets a list of values (or multiple connections).

typed lists?

• list shouldn't be a type like any other
  • allow connection List<T> -> T
  • allow connection T -> List<T> (make a one-element list, or actual list if the module loops)

• RR proposes: don't duplicate modules to loop, just make update() call compute() several times

• probably needs the dont-use-modules-as-data work -- modules that return themselves are going to break

• add logic in vistrails_module:Module:
  

if inputport T and input list<T>, call compute several times and build list of outputs

• coupling problem

  def test_module(a:T, b:T) -> (c:T, d:T):
  c = a*b
  d = a+b
  test_module([1, 2], [3, 4])

  • is it c = [3, 8], d = [4, 6]? (pairwise)
  • is it c = [3, 4, 6, 8], d = [4, 5, 5, 6]? (cartesian)
  • can probably be settable in module conf (and default to pairwise)

Implementation

The controlflow package did not take advantage of the improvements that can be made by modifying the vistrails core. Utilizing this we can make looping over modules more integrated. The branch automatic-loops contains a working version using a ListOf module type. Using a ListOf module as an input will cause the inputs to be looped over and the results returned as new ListOf modules. This means the downstream will be iterated automatically until a ListOf input port is used.

The ListOf type system is very basic and could be improved.

Cartesian product should be implemented by making it selectable on the module.

Choices for activating the loop:

1. Activate on multiple connections or list input on non-list port. This breaks current uses of multiple input connections like on the List module. Also, list of list is ambiguous.
2. Activate when using ListOf as input. Need an extra module to construct a ListOf input. This is the current choice.
3. Activate by setting a flag on the module. We could then loop over inputs as in 1. Iterating downstream modules would have to be set explicitly.

While module

Could be a module setting specifying delay and which output to check.

References

How Taverna does it: http://dev.mygrid.org.uk/wiki/display/taverna/Loops