Tue Apr 2 09:35:29 EDT 2013


Maybe it's best to first separate out the type unification problem to
simplify the ai-array code a bit.  Hmm... it seems impossible to
separate the structure from the typing..

There might be a big confusion going on here..  What I want in the end
is to reduce everything to a single setup routine and a single update
routine.  Can't this be solved at the type level?  The trouble is the
implicit "subsampling" operation.

Maybe this can be solved through an extra primitive?  I.e. p_hold Hold
takes any computation and projects it down to a sample that is
constant over the update loop.  This gives a "typing bridge".  The
remaining problem is then to perform state setup.

This allows setup code to be simpler:

  setup:  (s,i,t)   -> (s,l)
  update: (s,i,l,t) -> (s,o)
  comp:   (s,i)     -> (s,o)

As a result, this should give a single loop expression where each node
either depends on t or not.  If it doesn't, it can be hoisted out of
the loop.

Let's try the typing first.

The problem is too convoluted to solve at once.  How to break it down?

Hack: split all loop-local nodes?

No.  Split all inputs passed to setup and wrap them with "p_hold".
While this duplicates the whole network, it should do the right thing
in combination with lazy eval.

This is essentially the same hack as "const".

It doesn't seem possible or desirable to separate things by separating
setup and update functions.