Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Setting x-range in haskell-chart (Nathan H?sken)
2. Exercise of "Programming with Arrows" (Thiago Negri)
3. Re: Exercise of "Programming with Arrows" (Kim-Ee Yeoh)
4. Re: Exercise of "Programming with Arrows" (Thiago Negri)
5. Re: Exercise of "Programming with Arrows" (Thiago Negri)
----------------------------------------------------------------------
Message: 1
Date: Mon, 07 Oct 2013 14:13:21 +0200
From: Nathan H?sken <[email protected]>
To: [email protected]
Subject: [Haskell-beginners] Setting x-range in haskell-chart
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hey,
I plot a chart where I use LocalTime for the x plot value.
I want to define what the range of the x axis is. So I try:
layout1_bottom_axis . laxis_generate .~ scaledAxis def (xmin,xmax)
where xmin, xmax :: LocalTime. This fails with:
No instance for (RealFloat LocalTime)
Anyone knows how I set the xrange correctly in chart?
Thanks!
Nathan
------------------------------
Message: 2
Date: Mon, 7 Oct 2013 14:05:24 -0300
From: Thiago Negri <[email protected]>
To: Haskell Beginners <[email protected]>
Subject: [Haskell-beginners] Exercise of "Programming with Arrows"
Message-ID:
<cablnezufyg59kx_dvh184ajn4sfachmdzvnof1iwpc7s-da...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
The paper "Programming with Arrows" of John Hughes gives some exercises to
do [1].
I'm trying to solve it and would like to receive a feedback if I'm doing it
right or not before reading the rest of the paper.
I didn't find the answers in the internet (if someone could point me to it,
please do so).
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).
The paper says that implementing "first" will be tricky, and it really is.
I've came up to the solution listed below, *is it right?*
*
*
*
*
module SP where
import Prelude hiding (id, (.))
import Control.Category
import Control.Arrow
data SP a b = Put b (SP a b) | Get (a -> SP a b)
runSP :: SP a b -> [a] -> [b]
runSP (Put b s) as = b:runSP s as
runSP (Get k) (a:as) = runSP (k a) as
runSP (Get k) [] = []
compose :: SP b c -> SP a b -> SP a c
compose (Put a s) g = Put a (compose s g)
compose (Get k) (Put a s) = compose (k a) s
compose f (Get k) = Get (\a -> compose f (k a))
instance Category SP where
id = arr id
(.) = compose
instance Arrow SP where
arr f = Get (\a -> Put (f a) (arr f))
first (Put a s) = Get (\(a', c) -> Put (a, c) (delayed (a', c) s))
first (Get k) = Get (\(a, c) -> firstWithValue (k a) c)
delayed :: (a, c) -> SP a b -> SP (a, c) (b, c)
delayed (a, c) (Put b s) = Put (b, c) (delayed (a, c) s)
delayed (a, c) (Get k) = firstWithValue (k a) c
firstWithValue :: SP a b -> c -> SP (a, c) (b, c)
firstWithValue (Put a s) c = Put (a, c) (firstWithValue s c)
firstWithValue (Get k) _ = Get (\(a, c) -> firstWithValue (k a) c)
input :: [(String, String)]
input = [("a1", "a2"), ("b1", "b2"), ("c1", "c2"), ("d1", "d2")]
myArrow :: SP (String, String) (String, String)
myArrow = (delay "db1" >>> delay "da1") *** (delay "db2" >>> delay "da2")
delay :: a -> SP a a
delay b = Put b (arr id)
main :: IO ()
main = let output = runSP myArrow input in mapM_ f output
where f (a, b) = putStrLn $ "(" ++ show a ++ ", " ++ show b ++ ")"
*
*
The output of "main" is:
*SP> main
("da1", "da2")
("da1", "db2")
("da1", "a2")
("db1", "a2")
("a1", "a2")
("b1", "b2")
("c1", "c2")
("d1", "d2")
[1] http://www.cse.chalmers.se/~rjmh/afp-arrows.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20131007/61bb8ad6/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 8 Oct 2013 02:30:34 +0700
From: Kim-Ee Yeoh <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [Haskell-beginners] Exercise of "Programming with Arrows"
Message-ID:
<capy+zdq1-g1n_-whyn0-ffrrocfpat9lef_wzvu1mutqlfp...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
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 <[email protected]> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20131008/bcabcbec/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 7 Oct 2013 18:08:22 -0300
From: Thiago Negri <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Exercise of "Programming with Arrows"
Message-ID:
<cablnezt7ti1pjh9bd+shm4f5nqcqkdjbpascev_euuonzyi...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
"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 <[email protected]>
> 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 <[email protected]> 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
> [email protected]
> 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-0001.html>
------------------------------
Message: 5
Date: Mon, 7 Oct 2013 18:31:14 -0300
From: Thiago Negri <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Exercise of "Programming with Arrows"
Message-ID:
<cablnezuoj8ckfw7aukwve+j54jck7izmg_wad5uea9yf8tw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 <[email protected]>
> "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 <[email protected]>
>
>> 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 <[email protected]> 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
>> [email protected]
>> 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.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 64, Issue 12
*****************************************
