<div dir="ltr">This is my first contact with QuickCheck, but does this test count as a proof that my implementation is correct?<div><br></div><div>QuickCheck shows 100 tests passed.</div><div><br></div><div><div>prop_a xs = runSP (f *** g) xs == runSP (first f >>> swap >>> first g >>> swap) xs</div>
<div> where swap = arr (\(a,b) -> (b,a))</div><div> f = arr (++"a")</div><div> g = arr (++"b")</div></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2013/10/7 Thiago Negri <span dir="ltr"><<a href="mailto:evohunz@gmail.com" target="_blank">evohunz@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="im">"<span style="font-family:arial,sans-serif;font-size:13px">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."</span><div>
<span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></div><div><font face="arial, sans-serif">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.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">I mean, I think I need to guarantee that this definition holds:</font></div><div><font face="arial, sans-serif"><br></font></div><div>
<font face="arial, sans-serif">`g *** f` is the same as `first g >>> swap >>> first f >>> swap`</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">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.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Is my line of tought correct?</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">I'll try to write some tests to verify this.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Thanks!</font></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/10/7 Kim-Ee Yeoh <span dir="ltr"><<a href="mailto:ky3@atamo.com" target="_blank">ky3@atamo.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><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.<div>
<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></div>Given<div><br><br>> data SP a b = Put b (SP a b) | Get (a -> SP a b)<br>
<br></div></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.<span><font color="#888888"><br><br>-- Kim-Ee</font></span></div><div><div class="gmail_extra">
</div></div></div></div></div></div>
<br></div></div>_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org" target="_blank">Beginners@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/beginners" target="_blank">http://www.haskell.org/mailman/listinfo/beginners</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>