On 1/11/2011 1:35 AM, Captain Freako wrote:
you need to study ArrowLoop and understand that. In the code
rec (y,s')<- arr f -< (x,s)
s<- delay s0 -< s'
the state is 'captured' in the recursive binding. i.e. just like in real
circuits the output state "s" is threaded back as an input.
The recursive binding is just sugar for the application of the loop
combinator. The signature of the loop combinator is
loop :: arrow (input, feedback) (output, feedback) -> arrow input output
with the loop combinator (with which recursive arrow bindings are
defined) the function could have been defined as...
liftAu f s0 = loop (second (delay s0) >>> arr f )
the delay is neccessary to break the recursion. i.e. to calculate the
next output and state the previous state is used.
> liftAu :: ((x,FilterState s)->(y,FilterState s)) -> FilterState s ->
FilterAu x y
> liftAu f s0 = proc x -> do
> rec (y,s')<- arr f -< (x,s)
> s<- delay s0 -< s'
> returnA -< y
I think I understand how the `returnA' in the last line of your
`liftAu' function is getting translated by those instance definitions
into:
c where
c = Automaton ( arr id&&& arr (const c) )
and, furthermore, how that is passing the supplied `y' into the first
element of the resulting couple. However, I don't understand how the
recursively defined `c' is capturing the modified filter state and
preserving it for the next call. It seems like the Automaton being
referred to by `c' is a newly constructed entity, which knows nothing
about the current state of the running Automaton.
Any help in understanding this would be greatly appreciated.
Thanks!
-db
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
