Mon Feb 18 15:20:34 CET 2013
I don't like the fact that I'm doing something special. I have to
write down the principles every time:
- Instantiate state variables for the outer *temporal*, keeping the
frontend purely functional.
- Provide a useful notation for *spatial* iteration. This mostly
boils down to the idea of "distribution".
A problem with the current approach is that loops are not represented
well, and types of "distributed" variables are not correct.
Due to the hidden nature of the state variables, the representation is
somewhat upside down: it seems easier to lift the primitives to stream
operations, than to use an explicit "for" structure where a scalar
variable is taken from a composite (array) object, but the operations
themselves remain scalar.
Something keeps escaping me: where do the hidden composite (vector)
state variables and scalar types meet?
Maybe lifting the primitives is simpler.
It reminds me of the Haskell approach, where all this is more obivous:
this is a problem of commutation of type constructors: there is an
isomorphy between different orders, but once you pick an order, the
implementation does have a specific look.
Let's stick with what works now, and simplify it.