Tue May 4 13:10:24 EDT 2010

Comment dumps

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
             and connections

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
inlined code).

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.