<div dir="ltr"><div><div><div><div class="gmail_extra">Hey Thiago,<br><br>First of all, congratulations for reading Hughes! Many of his papers are worth reading and re-reading for both beginners and experts alike.<br><br><div class="gmail_quote">
On Tue, Oct 8, 2013 at 12:05 AM, Thiago Negri <span dir="ltr"><<a href="mailto:evohunz@gmail.com" target="_blank">evohunz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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).</blockquote></div><br>Given<br><br>> data SP a b = Put b (SP a b) | Get (a -> SP a b)<br>
<br></div><div>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!<br>
<br></div><div>The exercise asks for an implementation of the following Arrow instance:<br></div><div><br></div>> first :: arr a b -> arr (a,c) (b,c)<br><br></div>which, specialized to our case, is just SP a b -> SP (a,c) (b,c).<br>
<br></div>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.<br>
<br></div>So one way to look at this is as a buffering problem.<br><div><div><div><div><br>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.<br>
</div><div><br></div><div>Your main function doesn't seem adequate for the task.<br><br>-- Kim-Ee</div><div><div class="gmail_extra">
</div></div></div></div></div></div>