[<<][meta][>>][..]
Mon May 27 09:13:45 EDT 2013

for/n

Looks like this is going to be the better abstraction.
Next: see if it can support the "bus" structure.

Because of the auto-lifting (dual representation?) the input lists do
not need to be mentioned explicitly.  I'm still not sure if this is a
good idea.  It complicates things, but seems necessary to implement
the time feedback state threading.

Or is it?  Currently the loop indices are known at the time the state
feedback is performed, so it is possible to infer those without
relying on typing tficks.  But on the other hand, why not infer the
input indexing if the state indexing is already inferred?

It remains a point of confusion.  Why?  Because it is different..


What about this:
- for/n only needs state inputs for body, rest can be bound elsewhere
- feedback/n uses the same interface

So, the basic conceptual abstraction is state feedback, with two
iteration mechanisms: time and space.

Auto-lifting makes it possible to avoid having to specify array
inputs.  The same is probably true for the feedback/n

Roadmap:
- later: make for/n feedback/n use the same interface
- now: replace reduce/n with for/n in bus




[Reply][About]
[<<][meta][>>][..]