Sun Jan 27 18:44:18 CET 2013

Macros, combinators, circuits.

Maybe it's time for some harder questions.  What is the real
difference between higher order functions and higher order forms?
Meaning, there are ways to implement abstract combinators without the
need for higher order functions, but this means the combinators are
not functions themselves, i.e. some kind of strict order of
combinators. (E.g. Backus' Function level programming [1]).

A lot of vague ideas and I'm not sure what to do with them.

I'm missing a key insight.

What is a loop?

Can the data/codata idea help?

A loop is the dual of a data structure, e.g. an array <-> linear
iteration over elements.

Is there something as a canonical combinator?
Meaning, if you know the data type, you know the iteration pattern.
Yes, probably, but does that help?

Where to look... It seems from a wider application point, restricted
recursion is a good way to go.  Essentially, what I'm looking for is a
specification of a largely static collection of mathematical
operations on data aquired over time, possibly in blocks.

Currently there is already one operator: feedback, implemented by
feeding back the first n I/O streams.  The same could be done for
mapping onto vectors.

Maybe the thing should be kept more functional: don't think about
"running the same code more than once", but think in terms of varaible
binding.  What a stream processor really is, is a *duplication* of the
same functionality, bound on some kind of data flow grid.  That is the
fundamental viewpoint.  Combinators are then ways to build grids from
smaller, *functional* 

I.e. think in circuits.  Loops combined with memory are just a way to
implement self-similarity of circuits.

So, currently there is really only one combinator or "circuit
duplicator", which maps a functional i->o network on 

- first n_s I/O        -> causal feedback
- next n_i I and n_o O -> streams
- last n_p I           -> constants

what is missing is an explicit mention of initial state and final
combinator (something that reduces the last output).

This is `for/fold' with outputs.

Nice, but that doesn't bring much bread on the plank..

[1] http://en.wikipedia.org/wiki/Function-level_programming