One more question on the `runAuto' code, John: If I understand the code correctly, `f' is an arrow. Yet, we're using it on the right side of `=' in a simple assignment. How are we getting away with that? Thanks, -db On Wed, Oct 19, 2011 at 3:02 PM, John Lask wrote:

On 20/10/2011 5:11 AM, Captain Freako wrote:

for your use case then, the StateArrow seems more appropriate as it provides you with the final state. Ofcourse the Automaton arrow could also be used:

...

liftAu' f s0 = proc x -> do    rec (y,s') <- arr f -< (x,s)        s <- delay s0 -< s'    returnA -< (y,s)

this explicitly returns the state with evry value. However, you then need to manually thread the state through.

note: the arrow "plumbing" is only used when you start composing filters, with arrow combinators. If your not doing any composition as such then lifting your functions into the "arrows" is not buying you much.

...

John Lask wrote:

...

This is literate code. It expounds on your initial question and provides two solutions based either on the StateArrow or Automaton.... (Remainder omitted.)

John,

Thanks so much for your help! I'm going to study your example code and try to understand how the Automaton implicit plumbing is being used. (I'm determined to get my head around this arrow concept, damn it! ;-) )

I wonder if I might pester you for the final piece of the puzzle here: When the processing of the input stream through the filter is complete, I need to pass the final filter state, along with the output stream, back to the calling program. (This is because the calling program is going to split the input signal into conveniently sized chunks, calling my filter routine several times, in order to process the entire input stream. It expects to be able to pass an initial filter state into my routine, which is just the final state of the filter that I passed back to it after the previous call. In this way, we avoid inserting any edge artifacts at the input stream segmentation boundaries.)

So, is it possible to `fetch' the final state out of that Automaton, when it's finished processing the input list?

Thanks! -db

Hi David, I was referring to the `f' in the `runAuto' function, not the `liftAu' function. -db On Wed, Oct 19, 2011 at 8:53 PM, David Barbour wrote:

On Wed, Oct 19, 2011 at 8:07 PM, Captain Freako wrote:

...

One more question on the `runAuto' code, John:

If I understand the code correctly, `f' is an arrow. Yet, we're using it on the right side of `=' in a simple assignment. How are we getting away with that?

Thanks, -db

...

liftAu' f s0 = proc x -> do    rec (y,s') <- arr f -< (x,s)    s <- delay s0 -< s'    returnA -< (y,s)

The value `f` is a function - a parameter of liftAu'. While all functions are arrows (Arrow is defined on (->)), the value `arr f` is an arrow of the automaton model. The `=` symbol is used to define the liftAu function. What are you imagining?

On 21/10/2011 3:00 AM, David Barbour wrote: the f in (Automaton f) is a pure funtion runAuto is deconstructing the arrow by pattern matching then applying the function to the input to obtain the result and the continuation. i.e. runAuto takes an arrow and applies it to a value.

On Thu, Oct 20, 2011 at 5:19 AM, Captain Freakowrote:

...

Hi David,

I was referring to the `f' in the `runAuto' function, not the `liftAu' function.

-db

Ah, I see. You quoted one thing and spoke of another, and I got all confused. Keep in mind that functions are arrows (instance Arrow (->)).

...

type FilterAu b c = Automaton (->) b c runAuto :: FilterAu b c -> [b] -> [c] runAuto a [] = [] runAuto (Automaton f) (x:xs) = let (y,a) = f x in y:runAuto a xs