[Haskell-beginners] Exercise of "Programming with Arrows"

[Thiago Negri]

"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 at 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 at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20131007/1c874cb6/attachment.html>