- Haskell-Cafe - Haskell.org

GHC API question: Getting access to cpp processed source
by AlanKim Zimmerman 11 Sep '13

11 Sep '13

Hi Cafe I have just discovered that GHC.getTokenStream fails if it is used on a module with CPP directives in it. This is reported in http://ghc.haskell.org/trac/ghc/ticket/8265 Is there an easy way to get access to the pre-processed source, without having to explicitly write it to an output file in a temporary location? In other words an equivalent to getModuleSourceAndFlags that does the right thing. This currently prevents HaRe from processing files with preprocessor directives in them, I would like to come up with a workaround for current GHC versions, rather than having to wait for a future one. Regards Alan

3 4

Reasoning about performance
by Scott Pakin 10 Sep '13

10 Sep '13

I'm a Haskell beginner, and I'm baffled trying to reason about code performance, at least with GHC. For a program I'm writing I needed to find all pairs of elements of a list. That is, given the list "ABCD" I wanted to wind up with the list [('A','B'),('A','C'),('A','D'),('B','C'),('B','D'),('C','D')], where the order of elements in the resulting list is immaterial, but I don't want both ('A', 'B') and ('B', 'A'), for example. My first attempt looked like this: allPairs1 :: [a] -> [(a, a)] allPairs1 [] = [] allPairs1 (x:xs) = map (\a -> (x, a)) xs ++ allPairs1 xs Benchmarking with ghci's ":set +s" reveals the following performance (median of three runs shown): $ ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :!ghc -c -O2 allpairs.hs Prelude> :load allpairs Ok, modules loaded: AllPairs. Prelude AllPairs> :m +Control.DeepSeq Prelude Control.DeepSeq AllPairs> :show modules AllPairs ( allpairs.hs, allpairs.o ) Prelude Control.DeepSeq AllPairs> :set +s Prelude Control.DeepSeq AllPairs> deepseq (allPairs1 [1..10000]) True True (4.85 secs, 4004173984 bytes) A colleague suggested getting rid of the list append as follows: allPairs2 :: [a] -> [(a, a)] allPairs2 [] = [] allPairs2 (x:xs) = allPairs2' x xs xs where allPairs2' x [] [] = [] allPairs2' x (y:ys) zs = (x,y) : allPairs2' x ys zs allPairs2' x [] (z:zs) = allPairs2' z zs zs Not surprisingly, that runs faster: Prelude Control.DeepSeq AllPairs> deepseq (allPairs2 [1..10000]) True True (2.14 secs, 4403686376 bytes) I then figured I could do even better by rewriting the code tail-recursively: allPairs3 :: [a] -> [(a, a)] allPairs3 [] = [] allPairs3 (x:xs) = allPairs3' x xs xs [] where allPairs3' :: a -> [a] -> [a] -> [(a, a)] -> [(a, a)] allPairs3' h (x:xs) ys result = allPairs3' h xs ys ((h, x):result) allPairs3' _ [] (y:ys) result = allPairs3' y ys ys result allPairs3' _ [] [] result = result This takes half the memory as the above (yay!) but runs substantially *slower* (and appears to be thrashing my computer's memory system): Prelude Control.DeepSeq AllPairs> deepseq (allPairs3 [1..10000]) True True (10.58 secs, 2403820152 bytes) What gives? Why does my tail-recursive implementation run even slower and presumably produce more garbage than my initial, naive implementation? Is there some optimization GHC is performing for allPairs1 and allPairs2 that it can't apply to allPairs3? Similarly, how should I, as a newcomer who wants to write efficient Haskell code, reason about whether a code change is likely to improve rather than degrade performance? Guidelines like "per-iteration appends = bad" and "tail recursion = good" are great, but the preceding data indicate that something subtler is taking precedence over those guidelines with respect to code performance. Thanks in advance, -- Scott

5 8

Mistakes in documentation for weak pointers?
by Heinrich Apfelmus 10 Sep '13

10 Sep '13

Dear café, I'm currently studying weak pointers in order to implement garbage collection for a small JavaScript FFI used by the threepenny-gui library [1]. While the paper [2] is fairly clear, it seems that the documentation in System.Mem.Weak [3] differs in certain aspects. Could someone help me and clarify this? I have two questions: 1. The sentence in the documentation "References from the finalizer to the key are treated in the same way as references from the value to the key: they do not keep the key alive." seems incorrect in the subordinate clause. Namely, the paper only states that the weak pointer object does not keep the key alive. However, I understood that it is perfectly acceptable for the value to keep the key alive, and that this relation is not changed by mkWeak . Is this still correct? (The memo table example in the paper never stores the value itself, only a weak pointer to it, so it doesn't matter whether the value is reachable from the key or not.) 2. The sentence in the documentation "A heap object is reachable if: ... It is a weak pointer object whose key is reachable." seems to differ from the paper, which states that while weak pointers are always retained if their keys are alive, they can very much be unreachable. But if I think about it, the formulation in the documentation seems to be equivalent to the paper (as far as the semantics are concerned, it does not matter whether unreachable weak pointers are tombstoned or not.). Is that correct? [1]: http://www.haskell.org/haskellwiki/Threepenny-gui [2]: http://community.haskell.org/~simonmar/papers/weak.pdf [3]: http://hackage.haskell.org/packages/archive/base/latest/doc/html/System-Mem… Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

1 0

Transforming AST parametrized with type
by Sergey Mironov 10 Sep '13

10 Sep '13

Hi. Pat asked a question [1] about AST parametrized with types. People suggest to use Functor machinery if possible. Have anything changed since them? Do we have a way to safely transform the tree like data Expr a = Id { id :: Id a } | Op { op :: Char, expra :: (Expr a) , exprb :: (Expr a) } data Id a = Id { name :: a } from Expr String to, say, Expr Int where Int names may represent some keys in the hash map? Regards, Sergey [1] - http://stackoverflow.com/questions/5434889/is-it-possible-to-use-syb-to-tra… PS sclv suggested to use synthesize from SYB to solve the problem. Could anyone provide me with example of this method?

1 0

Looking for GUI examples
by Sergey Mironov 10 Sep '13

10 Sep '13

Hi, Cafe. I'd like to write simple GUI utility containing tray icon and the menu. Could you please suggest Haskell example to make my start easier? Regards, Sergey

3 3

Lenses: Should I declare Getters?
by Charlie Paul 10 Sep '13

10 Sep '13

I've been looking through Edward Kmett's lens library, and I'm a bit befuddled about Getters. In my own code, why would I want to have something be a Getter instead of a plain function? As far as I can see, a plain function is simpler to use, and can be converted to a Getter with "to" if we want to use it as a Fold. Is there a situation where writing a Getter is superior than writing a function, then lifting it as needed? Thank you, Charles Paul

3 2

Re: [Haskell-cafe] [Haskell] Hackage 2 now available for beta testing
by Ross Paterson 10 Sep '13

10 Sep '13

On Mon, Sep 09, 2013 at 07:23:59PM +0100, Duncan Coutts wrote: > Well-Typed and the Industrial Haskell Group (IHG) are very pleased to > announce that Hackage 2 is now available for public beta testing. The > plan is to do the final switchover in late September, to coincide > with ICFP. > > http://beta.hackage.haskell.org/ What's the story with haddock documentation? I see that some packages have docs imported from the old server, some have newly generated docs, and some have none, but no indication whether a bot has tried to build it or not. There's mention of maintainer uploads of docs as a fallback, but I couldn't find where one would do that. (It would also need to document the flags needed to get the links right.)

2 1

resources on static analysis
by Maarten Faddegon 10 Sep '13

10 Sep '13

Dear list, I am interested in learning more about static analysis of Haskell code. Specifically of the relation between arguments of recursive and non-recursive calls. For example if we look at the ++ function from Prelude: (++) [] ys = ys (++) (x:xs) ys = x : xs ++ ys amongst others, we could infer the relations: ys_i+1 = ys_i (x:xs)_i+1 = xs_i Searching the web I found several tools (HLint, Haskabelle, Sourcegraph), but I am interested in the theory behind this. If you could recommend a paper or a book on this topic I would be grateful. Thanks, Maarten Faddegon

3 2

Please excuse brief service disruption
by John Wiegley 10 Sep '13

10 Sep '13

The e-mail services at haskell.org were switched from exim4 to postfix tonight, please excuse the service disruption. For about one hour e-mails were not being accepted to the mailing lists. All should be resolved now. -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net

1 0

This is a mail system test, please ignore
by John Wiegley 10 Sep '13

10 Sep '13

Testing the new e-mail services at haskell.org. -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net

1 0