Tue May 4 13:10:24 EDT 2010
Basic idea: dealing with Data Flow Networks, one usually wants two
different kinds of representation:
* FUNCTION: tuples -> tuples
* NETWORK: collection of primitives and compositions, i.e. nodes
The main operation for this is the conversion: NETWORK -> FUNCTION.
The other way is only possible trivially, i.e. abstracting a single
Function representation fits best for native embedding in Haskell,
and for abstract interpretation techniques it is probably also best
to use functional representation over specialized data types.
However, at some point an explicit representation of networks will
be necessary for both input (importing Pd patches) and output
(generating C code that uses C function calls instead of fully
The main differences between function composition and a DFN are
that a DFN has:
* Explicit intermediate nodes
* Implicit order of computations
After thinking about this for a while, it seems that the needed
abstraction is a `channel'. Something that can be bound _once_ to
a value, and read from as an input. I.e. it behaves as a number
Lifting pure function to channel functions seems straightforward:
channels are a Functor.
A dataflow representation of a function is just the Function
"opened up" with output nodes made explicit.