[Haskell-cafe] types and number of evaluation steps
Dear all, I have a question about evaluation with respect to types and currying. Consider this programm: import Debug.Trace -- add :: Integer - Integer - Integer add :: Int - Int - Int add x y = x + y f a b c = trace b (add x c) where x = trace a (add a b) main :: IO () main = do print (f 1 2 3) print (f 1 2 4) Compiled with ghc-7.0.3: $ ghc --make Main.hs -o main -O2 The function add has to types. When we use type Int - Int - Int, the programm produces b a 6 b a 7 as output which shows that the x from the where clause in f is evaluated twice. However, when we use type Integer - Integer - Integer, this will give b a 6 b 7 which shows that x is evaluated only once. This was rather unexpected to me. Why does the number of evaluation steps depend on a type? Can anybody explain this or give a hint? Thank you very much, Heinrich -- -- hoerde...@funktional.info www.funktional.info -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] types and number of evaluation steps
Different kinds of optimization. I expect you'd have different results even if you use one type, but different -O flags. On 18 Feb 2012, at 13:28, Heinrich Hördegen wrote: Dear all, I have a question about evaluation with respect to types and currying. Consider this programm: import Debug.Trace -- add :: Integer - Integer - Integer add :: Int - Int - Int add x y = x + y f a b c = trace b (add x c) where x = trace a (add a b) main :: IO () main = do print (f 1 2 3) print (f 1 2 4) Compiled with ghc-7.0.3: $ ghc --make Main.hs -o main -O2 The function add has to types. When we use type Int - Int - Int, the programm produces b a 6 b a 7 as output which shows that the x from the where clause in f is evaluated twice. However, when we use type Integer - Integer - Integer, this will give b a 6 b 7 which shows that x is evaluated only once. This was rather unexpected to me. Why does the number of evaluation steps depend on a type? Can anybody explain this or give a hint? Thank you very much, Heinrich -- -- hoerde...@funktional.info www.funktional.info -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] types and number of evaluation steps
Hi, this is true. The optimization only works with -O2. I'd like to have more details about what's going on. How can I make sure, that this optimization triggers? Heinrich On 18.02.2012 11:10, MigMit wrote: Different kinds of optimization. I expect you'd have different results even if you use one type, but different -O flags. On 18 Feb 2012, at 13:28, Heinrich Hördegen wrote: Dear all, I have a question about evaluation with respect to types and currying. Consider this programm: import Debug.Trace -- add :: Integer - Integer - Integer add :: Int - Int - Int add x y = x + y f a b c = trace b (add x c) where x = trace a (add a b) main :: IO () main = do print (f 1 2 3) print (f 1 2 4) Compiled with ghc-7.0.3: $ ghc --make Main.hs -o main -O2 The function add has to types. When we use type Int - Int - Int, the programm produces b a 6 b a 7 as output which shows that the x from the where clause in f is evaluated twice. However, when we use type Integer - Integer - Integer, this will give b a 6 b 7 which shows that x is evaluated only once. This was rather unexpected to me. Why does the number of evaluation steps depend on a type? Can anybody explain this or give a hint? Thank you very much, Heinrich -- -- hoerde...@funktional.info www.funktional.info -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- -- Funktionale Programmierung Dr. Heinrich Hördegen Gutenbergstr. 26 80638 München FON: +49 (89) 12 59 79 49 FAX: +49 (89) 12 59 79 50 hoerde...@funktional.info www.funktional.info -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best FRP package for newbie
Hi Arnaud, While not necessarily in line with the state of the art of FRP libraries, I can warmly recommend going through the parts of Paul Hudak's Haskell School Of Expression that cover the Functional Animation Library (FAL, basically a light version of Fran). The book introduces FRP concepts gently and FAL is really nice to work with, at least when it comes to the type of code that is discussed in that book. Good luck! //Adam On Feb 17, 2012, at 12:00 , haskell-cafe-requ...@haskell.org wrote: Hello, I am interested in exploring more in depth FRP. I had a look at the wiki page and started to explore reactive which looked promising at first glance and backed by quite a few articles and tutorials, but 1) it did not install properly on my haskell platform and 2) from the mailing-list archives it seems to have died a couple of years ago. So my question is : What package would you recommend me to get my hands dirty with FRP? I am mostly interested in things related to music and network programming, if that matters. Thanks in advance for your help, Arnaud ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] types and number of evaluation steps
Am 18.02.2012 um 11:56 schrieb Heinrich Hördegen: Hi, this is true. The optimization only works with -O2. I'd like to have more details about what's going on. How can I make sure, that this optimization triggers? You cannot. Common subexpression elimination is done by GHC very conservatively, because it can not only affect impure programs: it can also affects strictness/lazyness and worsen memory usage of pure code. Like the HaskellWiki says: If you care about CSE, do it by hand. Holger Heinrich On 18.02.2012 11:10, MigMit wrote: Different kinds of optimization. I expect you'd have different results even if you use one type, but different -O flags. On 18 Feb 2012, at 13:28, Heinrich Hördegen wrote: Dear all, I have a question about evaluation with respect to types and currying. Consider this programm: import Debug.Trace -- add :: Integer - Integer - Integer add :: Int - Int - Int add x y = x + y f a b c = trace b (add x c) where x = trace a (add a b) main :: IO () main = do print (f 1 2 3) print (f 1 2 4) Compiled with ghc-7.0.3: $ ghc --make Main.hs -o main -O2 The function add has to types. When we use type Int - Int - Int, the programm produces b a 6 b a 7 as output which shows that the x from the where clause in f is evaluated twice. However, when we use type Integer - Integer - Integer, this will give b a 6 b 7 which shows that x is evaluated only once. This was rather unexpected to me. Why does the number of evaluation steps depend on a type? Can anybody explain this or give a hint? Thank you very much, Heinrich -- -- hoerde...@funktional.info www.funktional.info -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- -- Funktionale Programmierung Dr. Heinrich Hördegen Gutenbergstr. 26 80638 München FON: +49 (89) 12 59 79 49 FAX: +49 (89) 12 59 79 50 hoerde...@funktional.info www.funktional.info -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best FRP package for newbie
As beginner I really liked reactive-banana. I used it in a inhouse project for the graphical user interface (wx) and I found it easier to use than the imperative approach. Unfortunately the reactive-banana-wx package seems to be broken on 7.2. On 2/18/12, Adam Duracz a...@duracz.net wrote: Hi Arnaud, While not necessarily in line with the state of the art of FRP libraries, I can warmly recommend going through the parts of Paul Hudak's Haskell School Of Expression that cover the Functional Animation Library (FAL, basically a light version of Fran). The book introduces FRP concepts gently and FAL is really nice to work with, at least when it comes to the type of code that is discussed in that book. Good luck! //Adam On Feb 17, 2012, at 12:00 , haskell-cafe-requ...@haskell.org wrote: Hello, I am interested in exploring more in depth FRP. I had a look at the wiki page and started to explore reactive which looked promising at first glance and backed by quite a few articles and tutorials, but 1) it did not install properly on my haskell platform and 2) from the mailing-list archives it seems to have died a couple of years ago. So my question is : What package would you recommend me to get my hands dirty with FRP? I am mostly interested in things related to music and network programming, if that matters. Thanks in advance for your help, Arnaud ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] types and number of evaluation steps
+ on Int is extremely cheap. It is always faster to add again rather than store the value. But Integer is a different story. Addition time on this type can grow to several minutes. 18.02.2012 13:28, Heinrich Hördegen пишет: Dear all, I have a question about evaluation with respect to types and currying. Consider this programm: import Debug.Trace -- add :: Integer - Integer - Integer add :: Int - Int - Int add x y = x + y f a b c = trace b (add x c) where x = trace a (add a b) main :: IO () main = do print (f 1 2 3) print (f 1 2 4) Compiled with ghc-7.0.3: $ ghc --make Main.hs -o main -O2 The function add has to types. When we use type Int - Int - Int, the programm produces b a 6 b a 7 as output which shows that the x from the where clause in f is evaluated twice. However, when we use type Integer - Integer - Integer, this will give b a 6 b 7 which shows that x is evaluated only once. This was rather unexpected to me. Why does the number of evaluation steps depend on a type? Can anybody explain this or give a hint? Thank you very much, Heinrich ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] types and number of evaluation steps
In case of +, the reason might be that it's cheap, but the function add could do something else than + (It was just a small example). Ok, thank you for your useful comments. I will read about cse. Heinrich On 18.02.2012 13:42, Victor Gorokgov wrote: + on Int is extremely cheap. It is always faster to add again rather than store the value. But Integer is a different story. Addition time on this type can grow to several minutes. 18.02.2012 13:28, Heinrich Hördegen пишет: Dear all, I have a question about evaluation with respect to types and currying. Consider this programm: import Debug.Trace -- add :: Integer - Integer - Integer add :: Int - Int - Int add x y = x + y f a b c = trace b (add x c) where x = trace a (add a b) main :: IO () main = do print (f 1 2 3) print (f 1 2 4) Compiled with ghc-7.0.3: $ ghc --make Main.hs -o main -O2 The function add has to types. When we use type Int - Int - Int, the programm produces b a 6 b a 7 as output which shows that the x from the where clause in f is evaluated twice. However, when we use type Integer - Integer - Integer, this will give b a 6 b 7 which shows that x is evaluated only once. This was rather unexpected to me. Why does the number of evaluation steps depend on a type? Can anybody explain this or give a hint? Thank you very much, Heinrich ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- -- hoerde...@funktional.info www.funktional.info -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] types and number of evaluation steps
* Holger Siegel holgersiege...@yahoo.de [2012-02-18 12:52:08+0100] You cannot. Common subexpression elimination is done by GHC very conservatively, because it can not only affect impure programs: it can also affects strictness/lazyness and worsen memory usage of pure code. Like the HaskellWiki says: If you care about CSE, do it by hand. How can it affect strictness or laziness? -- Roman I. Cheplyaka :: http://ro-che.info/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] types and number of evaluation steps
Am 18.02.2012 um 14:38 schrieb Roman Cheplyaka: * Holger Siegel holgersiege...@yahoo.de [2012-02-18 12:52:08+0100] You cannot. Common subexpression elimination is done by GHC very conservatively, because it can not only affect impure programs: it can also affects strictness/lazyness and worsen memory usage of pure code. Like the HaskellWiki says: If you care about CSE, do it by hand. How can it affect strictness or laziness? I don't know. HaskellWiki says so: http://www.haskell.org/haskellwiki/GHC_optimisations#Common_subexpression_elimination ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] types and number of evaluation steps
example = a + b + a + b exampleCSE = x + x where x = a + b With CSE we are introducing new thunk: x. 18.02.2012 17:38, Roman Cheplyaka пишет: * Holger Siegelholgersiege...@yahoo.de [2012-02-18 12:52:08+0100] You cannot. Common subexpression elimination is done by GHC very conservatively, because it can not only affect impure programs: it can also affects strictness/lazyness and worsen memory usage of pure code. Like the HaskellWiki says: If you care about CSE, do it by hand. How can it affect strictness or laziness? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] types and number of evaluation steps
I'm not sure you can. Why do you need it? Отправлено с iPad 18.02.2012, в 14:56, Heinrich Hördegen hoerde...@funktional.info написал(а): Hi, this is true. The optimization only works with -O2. I'd like to have more details about what's going on. How can I make sure, that this optimization triggers? Heinrich On 18.02.2012 11:10, MigMit wrote: Different kinds of optimization. I expect you'd have different results even if you use one type, but different -O flags. On 18 Feb 2012, at 13:28, Heinrich Hördegen wrote: Dear all, I have a question about evaluation with respect to types and currying. Consider this programm: import Debug.Trace -- add :: Integer - Integer - Integer add :: Int - Int - Int add x y = x + y f a b c = trace b (add x c) where x = trace a (add a b) main :: IO () main = do print (f 1 2 3) print (f 1 2 4) Compiled with ghc-7.0.3: $ ghc --make Main.hs -o main -O2 The function add has to types. When we use type Int - Int - Int, the programm produces b a 6 b a 7 as output which shows that the x from the where clause in f is evaluated twice. However, when we use type Integer - Integer - Integer, this will give b a 6 b 7 which shows that x is evaluated only once. This was rather unexpected to me. Why does the number of evaluation steps depend on a type? Can anybody explain this or give a hint? Thank you very much, Heinrich -- -- hoerde...@funktional.info www.funktional.info -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- -- Funktionale Programmierung Dr. Heinrich Hördegen Gutenbergstr. 26 80638 München FON: +49 (89) 12 59 79 49 FAX: +49 (89) 12 59 79 50 hoerde...@funktional.info www.funktional.info -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Functor in terms of Arrow
Dear HC, Does AFunctor below have a standard name? It's a generalization of the Functor class in terms of Arrow instead of (-): fmap :: Functor f = (i - o) - f i - f o afmap :: Arrow a, AFunctor f = a i o- a (f i) (f o) It pops up in less general form (AFunctor = []) in iterated functions (difference equations / state space models), where the arrow is the update function parameterized by state type: data Iter s i o = Iter ((s,i) - (s,o)) instance Arrow (Iter s) More concretely: afmap :: ((s,i) - (s, o)) - (s,[i]) - (s,[o]) afmap f (s,[]) = (s,[]) afmap f (s0, i:is) = (sn, o:os) where (s1, o) = f (s0,i) (sn, os) = afmap f (s1, is) f (s,i) = (s', s') where s' = s + i is = [1,1,1,1,1] os = afmap f (0,is) -- (5,[1,2,3,4,5]) Cheers, Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best FRP package for newbie
Thanks to all for your kind answers. I already installed reactive-banana and skimmed through the doc which is quite good and extensive: at least this is a good start. Should the need arise, I will not hesitate to tap into the knowledge and wisdom of the community ! Regards, Arnaud ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] types and number of evaluation steps
It doesn't matter. Laziness would be affected if, for instance, something is not evaluated without CSE and is evaluated with it. In your example either all or none of 'a' and 'b' get evaluated, depending on whether the top-level expression is evaluated. * Victor Gorokgov m...@rkit.pp.ru [2012-02-18 18:23:19+0400] example = a + b + a + b exampleCSE = x + x where x = a + b With CSE we are introducing new thunk: x. 18.02.2012 17:38, Roman Cheplyaka пишет: * Holger Siegelholgersiege...@yahoo.de [2012-02-18 12:52:08+0100] You cannot. Common subexpression elimination is done by GHC very conservatively, because it can not only affect impure programs: it can also affects strictness/lazyness and worsen memory usage of pure code. Like the HaskellWiki says: If you care about CSE, do it by hand. How can it affect strictness or laziness? -- Roman I. Cheplyaka :: http://ro-che.info/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] empty fields are dropped in bytestring csv
Hacky patch to fix this for future reference, against bytestring-csv-0.1.2,
cost center annotations used to anecdotally verify that the change doesn't
significantly impact performance, (interestingly the Alex lexer in
bytestring-csv appears to allocate 1.5GB while lexing a 1.6MB csv file!?)
Text/CSV/ByteString.hs
65c65
fields = [ unquote s | Item s - line ]
---
fields = [ unquote s | Item s - pline line]
76a77,86
pline fs@(Item x : []) = fs
pline (Item x : Comma : []) = {-# SCC plinea #-} Item x : Comma : Item
S.empty : []
pline (Item x : Comma : rs) = {-# SCC plineb #-} Item x : Comma : pline
rs
pline (Comma : []) = {-# SCC plinec #-} Comma : Item S.empty : Comma :
Item S.empty : []
pline (Comma : rs) = {-# SCC plined #-} Item S.empty : Comma : pline rs
pline (Newline : rs ) = []
pline [] = []
On 17 February 2012 23:16, Tom Doris tomdo...@gmail.com wrote:
the bytestring-csv package appears to have a bug whereby empty fields are
dropped completely from the row, which is different to Text.CSV , which
will return an empty field in the parse result. I'd argue this is a bug in
bytestring-csv, anyone know whether this has been raised before, or know of
a workaround?
Prelude Data.Maybe Data.List Text.CSV.ByteString Data.ByteString.Char8
parseCSV $ pack a,b,c\n1,2,3\n1,,9\n
Just [[a,b,c],[1,2,3],[1,9]]
-- the last row has two fields ^
Prelude Text.CSV parseCSV /tmp/err a,b,c\n1,2,3\n1,,9\n
Right [[a,b,c],[1,2,3],[1,,9],[]]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functor in terms of Arrow
Tom, On 19/02/2012, at 3:21 AM, Tom Schouten wrote: Does AFunctor below have a standard name? It's a generalization of the Functor class in terms of Arrow instead of (-): fmap :: Functor f = (i - o) - f i - f o afmap :: Arrow a, AFunctor f = a i o- a (f i) (f o) It pops up in less general form (AFunctor = []) in iterated functions (difference equations / state space models), where the arrow is the update function parameterized by state type: data Iter s i o = Iter ((s,i) - (s,o)) instance Arrow (Iter s) I think you can work with Arrow transformers instead. See: http://hackage.haskell.org/packages/archive/arrows/latest/doc/html/Control-Arrow-Transformer-Stream.html#t:StreamArrow It may be that you can generalise to arbitrary functors, but satisfying the Arrow laws may require some care. cheers peter -- http://peteg.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] hackage down
Hackage seems to be down: http://www.downforeveryoneorjustme.com/http://hackage.haskell.org Best, Ozgur ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
