February 2011 - Glasgow-haskell-users

StgExpr AST
by Chris Nicholls 10 Feb '11

10 Feb '11

Hello, Is there a way to get access to the STG syntax tree of a program using the GHC api? i.e. a function that returns something of type `StgExpr' that can be used in a way similar to this: example module = defaultErrorHandler defaultDynFlags $ do runGhc (Just libdir) $ do dflags <- getSessionDynFlags setSessionDynFlags dflags target <- guessTarget targetFile Nothing setTargets [target] load LoadAllTargets modSum <- getModSummary $ mkModuleName module p <- parseModule modSum t <- typecheckModule p d <- desugarModule t c <- return $ coreModule d s <- coreToStg c return s Thanks for any help, Chris

2 1

Deriviable type classes
by Simon Peyton-Jones 10 Feb '11

10 Feb '11

Friends Just a heads-up. Pedro is working on implementing "Generic Defaults", as described in his Haskell Symposium 2010 paper www.dreixel.net/research/pdf/gdmh_nocolor.pdf It will replace (and improve on) the "Derivable type classes" stuff in GHC at the moment, which was originally presented in a paper of that title that Ralf and I wrote in the 2000 Haskell workshop http://research.microsoft.com/en-us/um/people/simonpj/papers/derive.htm. The "Derivable type class" extension is barely used, I believe, and isn't even documented in the manual. So I propose to switch from one to the other, rather than to try to support both. This change will happen in GHC 7.2 or 7.4, depending on when Pedro is done. Please yell if you are a secret user of derivable type classes, so this change would discombobulate you. Simon

4 5

Dictionaries and full laziness transformation
by Akio Takano 10 Feb '11

10 Feb '11

Hi, I'm using GHC 7.0.1. I found that recursive overloaded functions tend to leak memory when compiled with full-laziness optimization on. Here is a simple case. -- TestSub.hs {-# LANGUAGE BangPatterns #-} module TestSub where {-# NOINLINE factorial #-} factorial :: (Num a) => a -> a -> a factorial !n !acc = if n == 0 then acc else factorial (n - 1) (acc * n) -- main.hs import TestSub factorial1 :: Int -> Int -> Int factorial1 = factorial main = do n <- readLn print $ factorial1 n 1 main This program should run in constant space, and compiled with -O0 or -O2 -fno-full-laziness, it does. However with -O2, it takes a linear amount of memory. The core for factorial looks like this: TestSub.factorial = \ (@ a_ajm) ($dNum_slz :: GHC.Num.Num a_ajm) -> let { a_slA :: GHC.Classes.Eq a_ajm [LclId] a_slA = GHC.Num.$p1Num @ a_ajm $dNum_slz } in let { lvl2_slC :: a_ajm -> a_ajm -> a_ajm [LclId] lvl2_slC = TestSub.factorial @ a_ajm $dNum_slz } in ... The problem is that lvl2_slC closure is created whenever factorial is applied to a Num dictionary, and kept alive until that application is GCed. In this program it never happens, because an application to the Num Int dictionary is referred to by the factorial1 CAF, and it recursively keeps the whole chain of closures alive. I know that full laziness transformation *sometimes* causes a space leak, but this looks like a bad result to me, because: - It looks like there is no point building a lot of equivalent closures, instead of one. - A lot of code can suffer from this behavior, because overloaded recursive functions are fairly common. For example, unfoldConvStream function from the latest iteratee package suffers from this problem, if I understand correctly. Does anyone have an idea on whether this can be fixed in GHC, or how to work around this problem? Regards, Takano Akio

3 2

my RULES don't fire
by Sebastian Fischer 10 Feb '11

10 Feb '11

Hello, I want to use the RULES pragma and cannot get my rules to fire. Here is a simplified example of what I'm trying. I define my own version of foldMap for lists: fold :: Monoid m => (a -> m) -> [a] -> m fold f = foldr mappend mempty . map f -- alternative, trying to avoid interference with foldr/build fusion -- fold _ [] = mempty -- fold f (x:xs) = f x `mappend` fold f xs {-# NOINLINE fold #-} I try using a NOINLINE pragma to make the firing of my rules (which involve fold) more robust. But they don't fire with or without NOINLINE. Also the uncommented version does not make a difference. I also define a function that creates a singleton list: single :: a -> [a] single x = [x] {-# NOINLINE single #-} Now I want to replace calls of `fold f . g single` (or eta-expanded versions of this) by `g f` using the following rules: {-# RULES "monoid fusion pointfree" forall f (g :: forall m . Monoid m => (a -> m) -> b -> m) . fold f . g single = g f; "monoid fusion pointed, general" forall f (g :: forall m . Monoid m => (a -> m) -> b -> m) b . fold f (g single b) = g f b; "monoid fusion pointed, for lists" forall f (g :: forall m . Monoid m => (a -> m) -> [a] -> m) xs . fold f (g single xs) = g f xs; #-} The variations of type signatures (including no signatures at all) for the pattern variables that I tried did not change anything for the better. I wrote the third rule only because the second gives a warning that I don't quite understand: Warning: Forall'd type variable b is not bound in RULE lhs fold @ m @ a $dMonoid f (g @ [a] $dMonoid (single @ a) b) I try out the rules using the following function that takes the role of `g` in the rules: idGen :: Monoid m => (a -> m) -> [a] -> m idGen _ [] = mempty idGen f (x:xs) = f x `mappend` idGen f xs {-# NOINLINE idGen #-} Again, I use NOINLINE just in case that would help the rules fire. Here is a main function where the rules should fire: main :: IO () main = do print ((fold id . idGen single) [[()]]) print (fold id (idGen single [[()]])) But they don't. Why don't the rules fire, what can I change such that they do, and what to get rid of the warning for the second rule (which I think is the one I should use)? Best regards, Sebastian Here is the output of -ddump-simple-stats (once with -fenable-rewrite-rules only and once with -O): # ghc --version The Glorious Glasgow Haskell Compilation System, version 7.0.1 # ghc -fenable-rewrite-rules -fforce-recomp -ddump-simpl-stats --make rules [1 of 1] Compiling Main ( rules.hs, rules.o ) ==================== Grand total simplifier statistics ==================== Total ticks: 0 1 SimplifierDone 1 # ghc -O -fforce-recomp -ddump-simpl-stats --make rules [1 of 1] Compiling Main ( rules.hs, rules.o ) ==================== FloatOut stats: ==================== 0 Lets floated to top level; 0 Lets floated elsewhere; from 4 Lambda groups ==================== FloatOut stats: ==================== 10 Lets floated to top level; 1 Lets floated elsewhere; from 5 Lambda groups ==================== Grand total simplifier statistics ==================== Total ticks: 144 34 PreInlineUnconditionally 1 eta_Xp5 1 g_amr 1 eta_amx 1 k_amJ 1 z_amK 1 f_amQ 1 g_amR 1 x_amS 1 k_an9 1 z_ana 1 g_anb 1 f_anf 1 xs_ang 1 eta_aoA 2 $dShow_aKW 2 x_aKX 1 ys_aVd 1 c_dmm 1 n_dmn 1 a_snX 1 a_so1 1 lvl_sod 1 lvl_soe 1 lvl_sof 1 lvl_sog 1 lvl_soh 1 lvl_soi 1 lvl_soj 1 a_son 1 a_sop 1 a_sV0 1 a_sV2 17 PostInlineUnconditionally 1 k_amv 1 f_amQ 1 g_amR 1 c_ani 1 n_anj 1 m_anI 1 k_anJ 2 $dShow_aoy 2 x_aoz 1 c_aVa 1 f_aVb 1 x_aVc 1 a_snV 1 a_snZ 1 lvl_sVA 15 UnfoldingDone 1 GHC.Base.build 1 GHC.Base.foldr 2 System.IO.print 1 GHC.TopHandler.runMainIO 2 GHC.Base.. 1 GHC.Base.mapFB 1 GHC.Base.$fMonadIO_$c>> 2 Main.main 2 System.IO.print1 2 GHC.Show.$fShow[]_$cshow 8 RuleFired 1 Class op >> 2 Class op show 2 Class op showList 1 fold/build 1 foldr/nil 1 map 8 LetFloatFromLet 8 62 BetaReduction 1 eta_Xp5 1 a_amq 1 g_amr 1 a_amt 1 b_amu 1 k_amv 1 z_amw 1 eta_amx 1 b_amH 1 a_amI 1 k_amJ 1 z_amK 2 b_amN 2 c_amO 2 a_amP 2 f_amQ 2 g_amR 1 x_amS 1 a_an7 1 b_an8 1 k_an9 1 z_ana 1 g_anb 1 a_and 1 a1_ane 1 f_anf 1 xs_ang 1 b_anh 1 c_ani 1 n_anj 1 a_anG 1 b_anH 1 m_anI 1 k_anJ 2 a_aox 2 $dShow_aoy 2 x_aoz 1 eta_aoA 2 a_aKV 2 $dShow_aKW 2 x_aKX 1 elt_aV7 1 lst_aV8 1 a_aV9 1 c_aVa 1 f_aVb 1 x_aVc 1 ys_aVd 1 a_dml 1 c_dmm 1 n_dmn 13 SimplifierDone 13

2 3

RFC: migrating to git
by Simon Marlow 10 Feb '11

10 Feb '11

It's time to consider again whether we should migrate GHC development from darcs to (probably) git. From our perspective at GHC HQ, the biggest problem that we would hope to solve by switching is that darcs makes branching and merging very difficult for us. We have a few branches of HEAD that are very painful to keep merged with HEAD, and we would almost certainly have more branches if the overhead were lower. In some sense the overhead is self-inflicted because we have the no-conflict policy in the mainline repository, but that is to avoid problems with darcs' merging algorithms (both performance and correctness). We are still using darcs v1 patches rather than v2, but there are known problems with v2 which are preventing us from upgrading. The darcs team have been making great strides with performance, but conflict handling remains a serious problem. The darcs roadmap doesn't show this being fixed in the near future http://wiki.darcs.net/Roadmap Rebase support is coming, and it does work, though the workflow is a bit laborious. Besides the branching/merging/conflict issue, switching to git would give us plenty of side benefits, notably via access to a wealth of tool support. Making contribution easy is important to us too, and there are a lot of people using git. The cost of switching is quite high, which is one reason we decided to stay with darcs last time. We have multiple repos that need to be converted, and for some of them, where the repo is being shared with other projects, we may have to mirror rather than convert in place. We're prepared to put in the effort if the gains would be worthwhile though (offers of help are more than welcome!). We're intrested in opinions from both active and potential GHC developers/contributors. Let us know what you think - would this make life harder or easier for you? Would it make you less likely or more likely to contribute? Cheers, Simon

34 81

Re: System.Posix.Signals weirdness
by Simon Marlow 08 Feb '11

08 Feb '11

> I'd expect the following program (compiled with ghc and without any > specieal flags) to produce > > Just (Exited ExitSuccess) > True > > but it produces > > Just (Exited ExitSuccess) > False > > on Debian Lenny (ghc-6.8), OpenBSD-current (ghc-6.12.3), OpenBSD-current > (ghc=7.0 from the 7.0 branch). > > module Main where > > import Data.IORef > import System.Posix.Process > import System.Posix.Signals > import System.Posix.Unistd > > main = do > caughtCHLD <- newIORef False > installHandler sigCHLD (Catch $ writeIORef caughtCHLD True) Nothing > pid <- forkProcess $ sleep 2 >> return () > s <- sleep 8 > getProcessStatus False False pid >>= print > readIORef caughtCHLD >>= print > > The sigCHLD handler is never called in this program. Is this expected > behaviour? If so, why? If you change the "sleep" to "threadDelay", you get the expected answer. The reason is that sleep is a foreign call, and in the unthreaded RTS no other threads can run while the foreign call is in progress, and that includes threads created to handle signals. When sleep returns, there isn't enough time before the main thread exits for the sigCHLD handler thread to run. threadDelay is more friendly and lets the RTS run other threads. You could also use -threaded, but then the sleep call will be interrupted by SIGVTALRM, so using threadDelay is better. Cheers, Simon

1 0

Alex Mason wants to stay in touch on LinkedIn
by Alex Mason 07 Feb '11

07 Feb '11

LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Alex Mason Alex Mason Computer Science Tutor at Australian National University Canberra Area, Australia Confirm that you know Alex Mason https://www.linkedin.com/e/3s7ug4-gjv7nt1u-3a/isd/2281459363/cVZraxml/ -- (c) 2011, LinkedIn Corporation

2 1

a compiled program is slower than byte code
by Kazu Yamamoto 07 Feb '11

07 Feb '11

Hello, If I compile the attach code with GHC of the newest ghc-7.0 darcs branch, the compiled program is much slower than byte code. This phenomenon does not exist in GHC 6.12.3. 6.12.3 runghc -- 6.23s user 0.59s system 98% cpu 6.912 total ghc -- 5.72s user 0.70s system 99% cpu 6.422 total ghc -O -- 5.70s user 0.67s system 99% cpu 6.376 total ghc -O2 -- 5.69s user 0.67s system 99% cpu 6.373 total ghc-7.0 runghc -- 6.43s user 0.10s system 99% cpu 6.593 total ghc -- 9.20s user 0.09s system 99% cpu 9.302 total ghc -O -- 9.20s user 0.09s system 99% cpu 9.298 total ghc -O2 -- 9.38s user 0.09s system 99% cpu 9.478 total Is this a bug? My environment is Mac which runs Snow Leopard. --Kazu ---- import System.IO n :: Int n = 10000 main :: IO () main = withFile "/dev/null" WriteMode $ \h -> hPutStr h . foldr1 (++) . replicate n . replicate n $ 'a' ----

1 0

System.Posix.Signals weirdness
by Matthias Kilian 06 Feb '11

06 Feb '11

Hi, I'd expect the following program (compiled with ghc and without any specieal flags) to produce Just (Exited ExitSuccess) True but it produces Just (Exited ExitSuccess) False on Debian Lenny (ghc-6.8), OpenBSD-current (ghc-6.12.3), OpenBSD-current (ghc=7.0 from the 7.0 branch). module Main where import Data.IORef import System.Posix.Process import System.Posix.Signals import System.Posix.Unistd main = do caughtCHLD <- newIORef False installHandler sigCHLD (Catch $ writeIORef caughtCHLD True) Nothing pid <- forkProcess $ sleep 2 >> return () s <- sleep 8 getProcessStatus False False pid >>= print readIORef caughtCHLD >>= print The sigCHLD handler is never called in this program. Is this expected behaviour? If so, why? Ciao, Kili

1 0

OSX i386/x86 and x86_64 - time to switch supported platforms?
by Max Cantor 04 Feb '11

04 Feb '11

The last 32-bit, Intel Mac was the Mac Mini, discontinued in August 2007. The bulk of them were discontinued in 2006, along with PowerPC Macs. Does it make sense to relegate OSX x86_64 to community status while the 32-bit version is considered a supported platform? Given that I'm far from experienced enough to be able to contribute meaningfully to GHC, I'm not complaining about anyone's efforts, just that those efforts might be a bit misallocated. I'd venture a guess that far more people are interested in running 64-bit GHC on OSX than in running GHC on what is now fairly antiquated hardware. mc

6 7