- Glasgow-haskell-users

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

(read getLine) + (read getLine)
by Tyson Whitehead 04 Mar '10

04 Mar '10

Consider what would happen if GHC optionally inserted a morphism on fexps (the expression at the head of an application) as it currently does with integer literals and optionally with string literals. A standard function call f x y would windup as morph (morph f x) y With the following basic classes -- Functor class F t where func :: (a -> b) -> t a -> t b -- Pointed class F t => P t where -- pure :: a -> t a -- Applicative class P t => A t where apply :: t (a -> b) -> t a -> t b -- Monad class A t => M t where join :: t (t a) -> t a we can define a standard set of morphisms -- Category class C a b where morph :: a -> b instance C (a -> b) (a -> b) where morph = id instance F t => C (a -> b) (t a -> t b) where morph = func instance P t => C (a -> b) (a -> t b) where morph f = func f . pure instance A t => C (t (a -> b)) (t a -> t b) where morph = apply instance A t => C (t (a -> b)) (a -> t b) where morph f = apply f . pure instance M t => C (t (a -> t b)) (t a -> t b) where morph f = join . apply f instance M t => C (t (a -> t b)) (a -> t b) where morph f = join . apply f . pure instance M t => C (a -> t b) (t a -> t b) where morph f = join . apply (pure f) instance M t => C (a -> t b) (a -> t b) where morph f = join . apply (pure f) . pure If GHC could correctly pick between them (possibly if just tried them from most specific to least?), then we would get the following transformation (read getLine) + (read getLine) --> morph (morph (+) (morph read getLine)) (morph read getLine) --> apply (func (+) (func read getLine)) (func read getLine) or, using the names in the standard library (include Control.Applicative), (<*>) (fmap (+) (fmap read getLine)) (fmap read getLine) which does the right thing. Anyway, thought I would throw it out there in case it could be made to work. Cheers! -Tyson

1 0

Issue with type families
by Tyson Whitehead 04 Mar '10

04 Mar '10

The following code {-# LANGUAGE FlexibleInstances, TypeFamilies #-} import Control.Applicative class Z t where type W t z :: t -> W t instance Z (a -> b) where type W (a -> b) = a -> b z = id instance Z (IO (a -> b)) where type W (IO (a -> b)) = IO a -> IO b z = (<*>) works fine, but if I try and generalize to from IO to the Applicative classes instance (Applicative m) => Z (m (a -> b)) where type W (m (a -> b)) = m a -> m b z = (<*>) I get the following error Temp.hs:10:9: Conflicting family instance declarations: type instance W (a -> b) -- Defined at Temp.hs:10:9 type instance W (m (a -> b)) -- Defined at Temp.hs:14:9 Failed, modules loaded: none. unless I remove one of the instances, and then it is happy. Is this correct? I don't claim to really understand the rules regarding type classes, but I can't see why these are overlapping. Thanks! -Tyson

2 4

stg-ap-1-upd-info
by Herk, Robert van 03 Mar '10

03 Mar '10

Hi All, I am optimizing a program to consume less memory. If I profile it with +RTS -hd, it reports to fill 50% of my memory with stg-ap-1-upd-info. Does this mean anything? Regards, Robert The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

2 1

I accidentally the Prelude
by Josef Svenningsson 03 Mar '10

03 Mar '10

Hi, It seems I've been able to mess up my ghc installation pretty badly. Here is what happens if I just try to invoke ghci from the prompt: $ ghci GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. <command line>: module `Prelude' is not loaded $ I have no idea what I did to end up in this situation. What I've been doing lately is reinstalling some packages. I also have another ghc installed but it's at a completely different place in the file system. The only thing I can think of is if cabal managed to somehow confuse the two ghcs and wrote some data in the wrong place. What I really would like to know is if there is a simple way to fix this without completely reinstalling ghc with all the libraries I have installed. Has anyone else experienced anything similar? If this is a potential bug I'd be happy to provide any data that might help track it down. Cheers, Josef

5 12