"On the one hand, indeterminate a's need to be fed in before indeterminate b's get pulled out. On the other hand, the c's need to behave as if they were in a no-op assembly line. One c goes in, the one (and same!) c drops out."

I agree with "no-op assembly line", but when I'm using `first` on a processor, I want to process the first stream *only*. The second stream should remain as it was not touched, so future processors will receive the same sequence from the second stream.

I mean, I think I need to guarantee that this definition holds:

`g *** f` is the same as `first g >>> swap >>> first f >>> swap`

If my implementation of `first` uses a real no-op assembly line for `c` (i.e., `arr id`), then I would lose the stream. As you said, I need to buffer the second stream while processing the first one.

Is my line of tought correct?

I'll try to write some tests to verify this.

Thanks!


2013/10/7 Kim-Ee Yeoh <ky3@atamo.com>
Hey Thiago,

First of all, congratulations for reading Hughes! Many of his papers are worth reading and re-reading for both beginners and experts alike.


On Tue, Oct 8, 2013 at 12:05 AM, Thiago Negri <evohunz@gmail.com> wrote:
Exercise 2 (section 2.5) is asking to create a Stream Processor that can map more than one output per input (e.g. 3 outcomes for a single consume of the stream).

Given


> data SP a b = Put b (SP a b) | Get (a -> SP a b)

it's easy to see that it's not just about more than one output per input. It's about n pieces of input producing m pieces of output, where (n,m) may even -- and probably does -- depend on previous inputs!

The exercise asks for an implementation of the following Arrow instance:

> first :: arr a b -> arr (a,c) (b,c)

which, specialized to our case, is just SP a b -> SP (a,c) (b,c).

It should now be apparent what the 'trickiness' is. On the one hand, indeterminate a's need to be fed in before indeterminate b's get pulled out. On the other hand, the c's need to behave as if they were in a no-op assembly line. One c goes in, the one (and same!) c drops out.

So one way to look at this is as a buffering problem.

At this point, I'd encourage you to think of some quickcheck tests you can write to convince yourself whether you have a right implementation or not.

Your main function doesn't seem adequate for the task.

-- Kim-Ee

_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners