Mon Jun 4 23:59:27 EDT 2018

Existential types for siso?

Is this actually necessary?  In current experiments, the fixed type
output syntax could be hidden inside the representation monad.

I must have reached that conclusion last time..  It no longer contains
the existential type.

EDIT: My notes are too messy.
There are still existential types to be able to work with explicit state.

But it doesn't really seem to be necessary as long as the "fix"
operator is part of the language in some form.  This allows state to
be tucked away into the implementation of the monad.

All the other applicative stuff seems really not so interesting when
there is only the time dimension.  It just moves between update
equation vs. infinite sequence view.

For Signal.hs, it might be useful when time and space dimensions can
be combined.

Here's the tradeoff:

- fix is external: state accumulation is handled by representing
  tuples and functions in the language.

- fix is internal: all state is hidden inside the implementation

I see no real reason for handling state explicitly.  It is supposed to
be hidden from view, and is much more straightforward to handle

So don't mix them yet.  Play wit the simpler version on PRU and Seq.
Add some C and maybe some space loops to arrive at RAI?