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

[Thiago Negri]

This is my first contact with QuickCheck, but does this test count as a
proof that my implementation is correct?

QuickCheck shows 100 tests passed.

prop_a xs = runSP (f *** g) xs == runSP (first f >>> swap >>> first g >>>
swap) xs
  where swap = arr (\(a,b) -> (b,a))
        f = arr (++"a")
        g = arr (++"b")



2013/10/7 Thiago Negri <evohunz at gmail.com>

> "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/0e01fc03/attachment-0001.html>