March 2010 - Glasgow-haskell-users

strictness of unused arguments
by Roman Beslik 12 Mar '10

12 Mar '10

Hi all. I provide a sample program which causes a strange behavior of strictness analyzer. variant 1 {{{ module StrictUnusedArg (main) where f2 :: Int -> Int -> Int f2 x1 = if x1 == 0 then (\x0 -> x0) else let y = x1 - 1 in f3 y y f3 :: Int -> Int -> Int -> Int f3 x2 = if x2 == 0 then f2 else let y = x2 - 1 in f4 y y f4 :: Int -> Int -> Int -> Int -> Int f4 x3 = if x3 == 0 then f3 else let y = x3 - 1 in \x2 x1 x0 -> f4 y x2 x1 (y + x0) main = print (f2 100 0) }}} I expect that all arguments will be unboxed. "-ddump-simpl" reveals that actually types are {{{ f2 :: Int# -> Int -> Int f3 :: Int# -> Int -> Int -> Int }}} So when "f3" calls "f2" it unboxes the argument named "x1" and when "f2" calls "f3" it boxes the argument named "x1". "-ddump-stranal" knows strictness only for the "x2" of "f3" and "x1" of "f2". {{{ f2: [Arity 1 Str: DmdType U(L)] f3: [Arity 1 Str: DmdType U(L)] }}} I also can force the analyzer to think that "x1" and "x0" are strict by eta-expanding "f3": variant 2 {{{ f3 x2 x1 x0 = if x2 == 0 then f2 x1 x0 else let y = x2 - 1 in f4 y y x1 x0 }}} "-ddump-stranal" yields: {{{ f3: [Arity 3 Str: DmdType U(L)U(L)U(L)m] f2: [Arity 2 Str: DmdType U(L)U(L)m] }}} I even do not use ($!). So, the questions: Is it possible to change the strictness analyzer so it will treat "variant 1" as "variant 2"? Are these changes big? Compiled with options: $ ghc --make -fstrictness -fPIC -O3 -fforce-recomp blah-blah-blah $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.1 -- Best regards, Roman Beslik.

2 4

undocumented cost centres with -hd and -hy
by Soenke Hahn 12 Mar '10

12 Mar '10

When using the heap profiling options -hd (profiling by closure description) and -hy (profiling by type) there are some compiler-generated cost centres, for example "PAP", "MUT_ARR_PTRS_FROZEN" and "BLACKHOLE". I wasn't able to find documentation on them. Is there any? Thanks, Sönke

3 2

ghc ftp site
by Gregory Wright 09 Mar '10

09 Mar '10

Hi, Could someone tell me who is in charge of the ghc ftp site these days? I need to upload a bootstrap compiler to build MacPort's ghc on Snow Leopard and the permissions of the 6.10 - 6.1 directories have changed. I no longer can write there. Best Wishes, Greg

1 0

nasty things possible with generalized newtype deriving
by Wolfgang Jeltsch 09 Mar '10

09 Mar '10

Hello guys, are you following this Haskell Cafe thread: <http://www.mail-archive.com/haskell-cafe@haskell.org/msg72300.html> Seems that you can do ugly things with GHC’s current implementation of generalized newtype deriving. For example, you can easily construct sets with corrupted internal structure even if there are no bogus Ord instances. Best wishes, Wolfgang

1 0

Re: Equality constraint type mismatch
by C Rodrigues 09 Mar '10

09 Mar '10

(Hotmail is again swallowing newlines--sorry for the re-post) I see. The type inference algorithm requires type variables to be type constructors, not functions. Equality constraints are simplified assuming that is the case. I knew that type functions had to be fully applied, but I didn't know that they also couldn't be "taken apart" by unification. This explains why the following doesn't typecheck: type family T a :: * my_id :: f a -> f a; my_id = id x :: T a -> T a; x = my_id IMHO, this was not clear from the documentation or from the error message (It certainly _looks_ like "T a" should match "f a"...). Thanks for the explanation. -heatsink _________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/201469227/direct/01/

2 1

Re: Equality constraint type mismatch
by C Rodrigues 08 Mar '10

08 Mar '10

I see. The type inference algorithm requires type variables to betype constructors, not functions. Equality constraints aresimplified assuming that is the case. I knew that typefunctions had to be fully applied, but I didn't know that they alsocouldn't be "taken apart" by unification. This explains why thefollowing doesn't typecheck:type family T a :: *my_id :: f a -> f a; my_id = idx :: T a -> T a; x = my_idIMHO, this was not clear from the documentation or from the errormessage (It certainly _looks_ like "T a" should match "f a"...).Thanks for the explanation.-heatsink _________________________________________________________________ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. http://clk.atdmt.com/GBL/go/201469226/direct/01/

1 0

Re: [Haskell-cafe] ghc leaking memory?
by Simon Marlow 08 Mar '10

08 Mar '10

On 08/03/2010 13:30, Joachim Breitner wrote: > Hi Simon, > > Am Montag, den 08.03.2010, 11:07 +0000 schrieb Simon Marlow: >>> On Sat, Mar 6, 2010 at 11:57 AM, Joachim Breitner<nomeata(a)debian.org> wrote: >>>> Hi, >>>> >>>> in Debian, we are having some problems building large libraries (such as >>>> agda, highlighting-kate, xmonad-contrib) on weaker architectures (sparc, >>>> armel, s390) which compile with -fvia-C, especially when building the >>>> profiling libraries. >>>> >>>> In the case of highlighting-kate, there were really issues with the >>>> code: A huge list of words which ghc seemed to try to inline caused it >>>> consuming a lot of memory. >>>> >>>> But in the case of agda, it even fails with relatively small modules: >>>> https://buildd.debian.org/fetch.cgi?pkg=agda&arch=sparc&ver=2.2.6-3&stamp=1… >>>> >>>> Now, looking at the memory gauge on my computer while compiling such a >>>> program with Cabal (which compiles all modules in one ghc call), it >>>> looks like it is steadily increasing. I’d expect ghc to free a lot of >>>> memory when it is done with a module, but this does not seem to be the >>>> case. >>>> >>>> Is this a bug (i.e. memory leak) in ghc or expected behavior? >> >> Can you verify that it is GHC leaking memory, and not gcc? I recommend >> turning off -fvia-C in particular unless you're sure that you need it. > > Sorry if I was not clear: The issues arise on “strange” architectures > (armel, s390, sparc, mips) where, as far as I know, -fvia-C is the only > option and thus the default. I was not setting this flag myself. Ah, I see. > Isn’t GHC calling gcc once for each module? In that case, that can not > leak across modules, can it? Right, gcc is only being invoked once per module, but the files being sent to gcc can get quite large, particularly when profiling is enabled, and even a single run of gcc can grow very large. This has been more of a problem with the newer gcc versions since they changed their memory manager and started doing whole-module optimisations (though we do try to disable this with -fno-toplevel-reorder, I'm not sure if that disbales module-at-a-time compilation completely). Cheers, Simon

1 0

Re: [Haskell-cafe] ghc leaking memory?
by Antoine Latter 08 Mar '10

08 Mar '10

Including ghc-users. On Sat, Mar 6, 2010 at 11:57 AM, Joachim Breitner <nomeata(a)debian.org> wrote: > Hi, > > in Debian, we are having some problems building large libraries (such as > agda, highlighting-kate, xmonad-contrib) on weaker architectures (sparc, > armel, s390) which compile with -fvia-C, especially when building the > profiling libraries. > > In the case of highlighting-kate, there were really issues with the > code: A huge list of words which ghc seemed to try to inline caused it > consuming a lot of memory. > > But in the case of agda, it even fails with relatively small modules: > https://buildd.debian.org/fetch.cgi?pkg=agda&arch=sparc&ver=2.2.6-3&stamp=1… > > Now, looking at the memory gauge on my computer while compiling such a > program with Cabal (which compiles all modules in one ghc call), it > looks like it is steadily increasing. I’d expect ghc to free a lot of > memory when it is done with a module, but this does not seem to be the > case. > > Is this a bug (i.e. memory leak) in ghc or expected behavior? > > Is there a way to make Cabal build each module on its own? > > Are there any fixes or work-arounds? > > Greetings, > Joachim > > -- > Joachim "nomeata" Breitner > Debian Developer > nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C > JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

3 2

Equality constraint type mismatch
by C Rodrigues 07 Mar '10

07 Mar '10

I would like help understanding a type error I'm getting with GHC 6.10.4. GHC reports a type mismatch for the types in a satisfiable equality constraint. The function "idLazy" below demonstrates the error. I would appreciate if someone can explain what's going on. Thanks, -heatsink {-# LANGUAGE TypeFamilies, EmptyDataDecls, ScopedTypeVariables, FlexibleContexts #-} module Test where import Control.Monad -- These types are used as type indices data Pure data Lazy -- Delayed evaluation in the IO monad data Delayed t a = Delayed (IO (t a)) {- This function definition gives me the error Test.hs:24:0: Couldn't match expected type `Delayed (t Pure)' against inferred type `t Lazy' But that's exactly what my constraint says! What's wrong? -} idLazy :: forall (t :: * -> * -> *). t Lazy ~ Delayed (t Pure) => Delayed (t Pure) Lazy -> Delayed (t Pure) Lazy idLazy x = x -- Below, I provide an instance of 't' that makes idLazy well-typed. -- A type-indexed data structure data Tree a = Leaf Int | Branch (Subtree a a) (Subtree a a) -- The first parameter to 'Subtree' determines what type the outermost -- constructor will have. The second parameter determines what type -- the inner constructors will have. type family Subtree a :: * -> * -- Two instances of the data structure type instance Subtree Pure = Tree type instance Subtree Lazy = Delayed Tree {- If I use this type signature, there is no error idLazy :: Subtree Lazy ~ Delayed (Subtree Pure) => Delayed (Subtree Pure) Lazy -> Delayed (Subtree Pure) Lazy -} _________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/201469227/direct/01/

2 1

halp! trying to build with LLVM
by Louis Wasserman 06 Mar '10

06 Mar '10

Hey, I'm trying to build GHC with LLVM. I need HEAD -- I tried, and can't get anywhere with STABLE -- so when I go and get HEAD, untar it, ./darcs-all get, and try to apply the llvm patch, I'm told that there are some other patches missing. So I run darcs pull. Everything's cool now, except when I try to run make: ........... [57 of 61] Compiling Distribution.Simple.Build ( libraries/Cabal/Distribution/Simple/Build.hs, bootstrapping/Distribution/Simple/Build.o ) [58 of 61] Compiling Distribution.Simple.Haddock ( libraries/Cabal/Distribution/Simple/Haddock.hs, bootstrapping/Distribution/Simple/Haddock.o ) [59 of 61] Compiling Distribution.Simple.Install ( libraries/Cabal/Distribution/Simple/Install.hs, bootstrapping/Distribution/Simple/Install.o ) [60 of 61] Compiling Distribution.Simple ( libraries/Cabal/Distribution/Simple.hs, bootstrapping/Distribution/Simple.o ) [61 of 61] Compiling Main ( utils/ghc-cabal/ghc-cabal.hs, bootstrapping/Main.o ) utils/ghc-cabal/ghc-cabal.hs:187:30: `programDefaultArgs' is not a (visible) field of constructor `ConfiguredProgram' utils/ghc-cabal/ghc-cabal.hs:188:30: `programOverrideArgs' is not a (visible) field of constructor `ConfiguredProgram' utils/ghc-cabal/ghc-cabal.hs:195:33: `programDefaultArgs' is not a (visible) field of constructor `ConfiguredProgram' utils/ghc-cabal/ghc-cabal.hs:200:33: `programOverrideArgs' is not a (visible) field of constructor `ConfiguredProgram' utils/ghc-cabal/ghc-cabal.hs:206:30: `programDefaultArgs' is not a (visible) field of constructor `ConfiguredProgram' utils/ghc-cabal/ghc-cabal.hs:207:30: `programOverrideArgs' is not a (visible) field of constructor `ConfiguredProgram' utils/ghc-cabal/ghc-cabal.hs:354:27: Not in scope: `programDefaultArgs' utils/ghc-cabal/ghc-cabal.hs:357:27: Not in scope: `programOverrideArgs' make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1 make: *** [all] Error 2 Halp! Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

2 1