ghc

Given the program: import Language.Haskell.Exts.Annotated -- from haskell-src-exts import System.Mem import System.IO import Control.Exception main :: IO () main = do evaluate $ length $ show $ fromParseResult $ parseFileContents $ "data C = C {a :: F {- " ++ replicate 400000 'd' ++ " -} }" performGC performGC performGC Using GHC 7.0.3, when I run: $ ghc --make Temp.hs -rtsopts && Temp.exe +RTS -G1 -S Alloc Copied Live GC GC TOT TOT Page Flts bytes bytes bytes user elap user elap ... 29463264 64 8380480 0.00 0.00 0.64 0.85 0 0 (Gen: 0) 20 56 8380472 0.00 0.00 0.64 0.86 0 0 (Gen: 0) 0 56

It is considered good practice to enable GHC warnings with -Wall . However, I've found out that fixing those warnings has a negative effect for some types of code constructs. Example 1: Using the do-notation equivalent of f >> will generate a warning if I don't explicitly use the _ <- f form: Warning: A do-notation statement discarded a result of type Char. Suppress this warning by saying "_ <- f", or by using the flag -fno-warn-unused-do-bind I understand that I can forget to do something with the result of f . However, it is legitimate to ignore the result (very common in parsers). There is

Haskell blew my mind yet again when I realised that (x,y) Is just syntactic sugar for (,) x y Naturally I wanted to extend this to larger tuples. But (,) x ((,) y z) Gave me (x,(y,z)) Which was not what I was looking for. On a whim, I tried (,,) x y z And it worked, giving exactly what I wanted: (x,y,z) This raised the question: How far can you take it? Much to my astonishment, there seemed to be no limit. All of the below are valid operators: (,) (,,) (,,,) (,,,,) --etc (,,,,,,,,,,,,,,) (,,,,,,,,,,,,,,,) --etc (,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,) --etc This behaviour is amazing and leads to

If I know a certain value is likely to survive its first encounter with the garbage collector, is there some way to let GHC know, so it can just allocate it directly somewhere outside the nursery? For instance, if I'm building up a large structure out of a bunch of smaller pieces, I know each piece will last at least until the whole structure is complete. In the GHC garbage collector there are no hooks for hinting at the generation an object should be allocated to. However, you might be able to exploit the operational behavior in a couple of ways: depending on the data type, you may be able to

When compiling a haskell source file using the -S option in GHC the assembly code generated is not clear. There's no clear distinction between which parts of the assembly code belong to which parts of the haskell code. Unlike GCC were each label is named according to the function it corresponds to. Is there a certain convention in these names produced by GHC? How can I relate certain parts in the generated assembly code to their corresponding parts in the haskell code? hammar For top level declarations, it's not too hard. Local definitions can be harder to recognize as their names get mangled

I'm reading up about the Lambda-Cube, and I'm particularly interested in System F-omega, which allows for "type operators" i.e. types depending on types. This sounds a lot like GHC's type families. For example type family Foo a type instance Foo Int = Int type instance Foo Float = ... ... where the actual type depends on the type parameter a . Am I right in thinking that type families are an example of the type operators ala system F-omega? Or am I out in left field? System F-omega allows universal quantification, abstraction and application at higher kinds , so not only over types (at kind *

With respect to how packages are created, installed and used in Haskell, what is the relationship between ghc-pkg and cabal ? What are their roles - when would you use one, over the other, or use both? Are they complementary tools, competitive tools, or simply tools that do different jobs? Graphically, the dependencies are: Packages GHC can use | Are registered with "ghc-pkg register" | And (almost always) built with Cabal | With build dependencies resolved by cabal-install | From Hackage. ghc-pkg is a direct interface to GHC's package database. Cabal is a tool that provides a consistent

I have used the ghci debugger but would really prefer if it was somewhat integrated with a text editor to simplify the process of setting breakpoints. It should probably not strictly evaluate every visible variable but at least simplify the process of looking at the local state. I recently found the trace function which has been helpful by allowing debug printouts from otherwise hard places. Norman Ramsey A good way to debug Haskell code is to write and test algebraic laws using QuickCheck and SmallCheck . There have been several Haskell debuggers including Hat, Hood, and Freya, but none of

The design of GHC is based on something called STG, which stands for "spineless, tagless G-machine". Now G-machine is apparently short for "graph reduction machine", which defines how laziness is implemented. Unevaluated thunks are stored as an expression tree, and executing the program involves reducing these down to normal form. (A tree is an acyclic graph, but Haskell's pervasive recursion means that Haskell expressions form general graphs , hence graph-reduction and not tree-reduction.) What is less clear are the terms "spineless" and "tagless". I think that "spineless" refers to the fact

Here's the scenario: I've written some code with a type signature and GHC complains could not deduce x ~ y for some x and y . You can usually throw GHC a bone and simply add the isomorphism to the function constraints, but this is a bad idea for several reasons: It does not emphasize understanding the code. You can end up with 5 constraints where one would have sufficed (for example, if the 5 are implied by one more specific constraint) You can end up with bogus constraints if you've done something wrong or if GHC is being unhelpful I just spent several hours battling case 3. I'm playing with