__color__,ticket,_cclen,cc,summary,component,version,milestone,owner,status,priority,_changetime,_description,_reporter
3,4385,763,"alexey.skladnoy@…, adam.gundry@…, sweirich@…, dimitris@…, byorgey@…, Conor.McBride@…, pumpkingod@…, as@…, leather@…, sjoerd@…, hesselink@…, erkokl@…, jeroen.weijers@…, conal@…, v.dijk.bas@…, helgikrs@…, nonowarn@…, djahandarie@…, christiaan.baaij@…, ghc@…, bjornbm, illissius@…, danlex@…, pho@…, dankna@…, favonia@…, jhenahan@…, reiner.pope@…, acfoltzer@…, nathanhowell@…, eir@…, douglas.mcclean@…, hvr@…, eric.pashman@…, Artyom.Kazak@…",Type-level natural numbers,Compiler (Type checker),,7.6.2,diatchki,new,normal,2013-06-18T16:09:35-0700,"Natural numbers at the type-level have many uses, especially in contexts where programmers need to manipulate data with statically known sizes.  A simple form of this feature has been present in many programming languages for a long time (e.g., sub-range types in Pascal, array type in C, etc.).  The feature is particularly useful when combined with polymorphism as illustrated by more recent programming languages (e.g., Cyclone, BlueSpec, Cryptol, Habit).

Existing features of Haskell's type system---such as polymorphism, kinds, and qualified types---make it particularly suitable for adding support for type level naturals in a natural way!

Indeed, there are quite a few Haskell libraries available on Hackage that implement support for type-level numbers in various forms.  These libraries are being used by other packages and projects (e.g., the Kansas Lava project, and the type-safe bindings to the LLVM library).

Supporting natural number types directly in the compiler would help these projects, and others, by improving on the existing libraries in the following ways:
  * a standard implementation,
  * a better notation,
  * better error messages,
  * a more efficient implementation,
  * more complete support for numeric operations.

I have started on an implementation of this feature, and my GHC branch is available in a darcs repository at the following URL:
{{{
http://code.galois.com/darcs/ghc-type-naturals/
}}}



",diatchki
3,1409,689,"dterei, pho@…, alfonso.acosta@…, mnislaih@…, lazycat.manatee@…, alexander.dunlap@…, id@…, lennart@…, ben.franksen@…, nr@…, ndmitchell@…, andres.sicard.ramirez@…, explicitcall@…, kolmodin@…, lambda-belka@…, analytic@…, tora@…, sveina@…, ganesh, illissius@…, hackage.haskell.org@…, skilpat@…, leon.p.smith@…, nathanhowell@…, singpolyma@…, hvr@…, ghc@…, roma@…, zaretskysa@…, eir@…, william.knop.nospam@…",Allow recursively dependent modules transparently (without .hs-boot or anything),Compiler,6.10.2,_|_,,new,normal,2013-01-06T18:48:19-0800,"Essentially, compile strongly-connected sets of modules like single modules are compiled (they have to have the same default and monomorphism-restriction, so it is like compiling one module, after the module/import fixpoint and name resolution are done).

This can increase the amount of recompilation necessary compared to using .hs-boot files, so it is probably desirable to still allow those.  Of course, manually keeping .hs-boot files and {-#SOURCE#-} pragmas around (and synchronized with the real code) is a nuisance (though informative if one cares about minimizing the amount of recursion).  I suspect that there can be situations where one level of export-subsets via .hs-boot files is not sufficient... (which would be one reason it wouldn't be easy to ""just"" treat a subset of each .hs file as its .hs-boot).

When not using --make mode, ghc would have to find the minimal module cycles somehow, and put just one "".hi-boots"" or "".his"", and .o I think, file somewhere (next to an arbitrary one of the modules I guess) in order that the compilation isn't repeated pointlessly for each module.  And deal with which compiler flags are used.  Maybe better not to allow it without --make.

In --make mode, such hackery should not be needed.  This might also help deal with (work around?) such existing bugs with recursive modules and --make: #930 , #1072 , #1133 .  The modules having different OPTIONS_GHC or LANGUAGE pragmas might still be tricky or impossible to accept, depending which ones they are and how much implementation effort it's worth investing in allowing that.  (Although, class instances being overlappable might be advantageous to have implemented a per-class not per-module specification anyway, for example, so pragmas that affect less than the whole module could be added more easily.)",Isaac Dupree
3,1496,277,"samb, chak@…, ganesh.sittampalam@…, lennart.augustsson@…, tom.schrijvers@…, df@…, mjm2002@…, pumpkingod@…, ben@…, jmaessen@…, hackage.haskell.org@…, ezyang@…",Newtypes and type families combine to produce inconsistent FC(X) axiom sets,Compiler (Type checker),6.7,7.6.2,simonpj,new,normal,2013-03-14T01:24:30-0700,"Given:

{{{
{-# OPTIONS_GHC -ftype-families #-}
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
data family Z :: * -> *

newtype Moo = Moo Int

newtype instance Z Int = ZI Double
newtype instance Z Moo = ZM (Int,Int)
}}}

We generate the axioms:

{{{
(from the instances)
Z Int ~ Double
Z Moo ~ (Int,Int)

(from the newtype)
Moo ~ Int
}}}

And can prove:

{{{
(production REFL in the FC(X) paper)
Z ~ Z

(production COMP)
Z Moo ~ Z Int

(production TRANS)
Z Moo ~ Double

(production SYM)
Double ~ Z Moo

(production TRANS)
Double ~ (Int,Int)
}}}

Tickling this seems to require the newtype cheat, but the inconsistant axioms
allow code to pass Core Lint and still crash:

{{{
newtype Moo = Moo Int deriving(IsInt)
class IsInt t where
    isInt :: c Int -> c t
instance IsInt Int where isInt = id
main = case isInt (ZI 4.0) of ZM tu -> print tu
}}}

{{{
stefan@stefans:/tmp$ ghc -dcore-lint Z.hs
stefan@stefans:/tmp$ ./a.out
Segmentation fault
stefan@stefans:/tmp$ ghc -V
The Glorious Glasgow Haskell Compilation System, version 6.7.20070612
stefan@stefans:/tmp$
}}}",sorear
3,3085,272,"ndmitchell@…, deduktionstheorem@…, conal@…, id@…, haskell@…, chevalier@…, vogt.adam@…, merehap@…, mmitar@…, shahn, hackage.haskell.org@…, pho@…",warn about language extensions that are not used,Compiler,6.10.1,7.6.2,,new,normal,2012-09-12T04:11:57-0700,"When I put

`{-# OPTIONS_GHC -Wall -Werror #-}`

in my source file, I don't get compiler warnings about redundant language extensions that I enabled in that file.

For example if I write

`{-# LANGUAGE GeneralizedNewtypeDeriving #-}`

in the file, but I never do newtype deriving, the compiler could give me a warning.

It would be nice if the compiler gave warnings about this, since after refactoring, some language extensions might not be needed anymore, and hence should be removed since fewer language extensions mean more stable and portable code no?

",PVerswyvelen
3,3557,272,"ghc@…, axman6@…, haskell.vivian.mcphail@…, pumpkingod@…, dterei, william.knop.nospam@…, Jake.McArthur@…, as@…, hackage.haskell.org@…, jystic@…, nightski@…, mle+hs@…",CPU Vector instructions in GHC.Prim,Compiler (NCG),6.11,_|_,,new,normal,2012-01-25T05:33:26-0800,"It would be nice to have support for vector unit (MMX, SSE, AltiVec, and so on) operations in GHC. Currently Data Parallel Haskell cannot utilize vector units due to GHC's lack of support.
Those vector operations could be nicely used to get e.g. stereo signal processing for the price of mono signal processing.
Maybe those operations could be added to GHC.Prim, or because there are so many, to a new module, GHC.Prim.Vector.
",guest
2,3472,271,"filcab+ghc@…, barsoap@…, marco.comini@…, pho@…, khaelin@…, CBa, ngwese@…, dbkirk@…, sudish@…, slyfox@…, middleton.ted@…, g@…, brian.bloniarz@…, karel.gardas@…",Porting through .hc files broken,Build System,6.12.1 RC1,7.8.1,,new,high,2012-09-12T03:30:53-0700,"I've been trying repeatedly over the past week or two to get an x86_64 build of GHC for OS X, by going through the procedure described at [http://hackage.haskell.org/trac/ghc/wiki/Building/Porting]. 

I've encountered several problems, and the process is huge and daunting so it's hard to say exactly what's a real error and what causes the breakage, but I'll try to describe what I've seen so far.

I've been treating the x86_64 unregistered build as a .hc port, so I effectively partitioned my box into two machines, one with a gcc that compiles to i386 by default and the other with one for x86_64. I follow the instructions on the page above and first generate the headers describing the 64-bit machine with the 64-bit compiler, then I copy them into another ghc tree, switch the gcc to i386 default, and do a build that keeps its .hc files. Most of it goes fine, and then I start getting massive errors about the assembly output being incorrect (which should be fine because all I want are the .hc files). So I follow the make -k and ignore the errors (although this is rather nerve-wracking as instructions saying ""just ignore any errors"" seem rather fragile). I then build the tarball with all the .hc files in it and unpack it in the other tree.

Now, I switch the gcc back to default x86_64, and go through the rest of the process described. My first issue is that the FB_ macro is inserting --- BEGIN --- explicitly into my assembly. This feels odd, as I'm doing an unregistered build. It seems that somehow the MINI_INTERPRETER macro and NO_REGS aren't getting defined, so the pre-mangler stuff is getting inserted into my assembly. I add -Ds for those to my build.mk and resume.

This goes smoothly for a while, and then I encounter an error:
{{{
make[1]: *** No rule to make target `rts/dist/build/Apply.o', needed by `rts/dist/build/libHSrts.a'.  Stop.
}}}
I check the rts directory and indeed there is an Apply.hc file in there. So I guess the build system forgot that .hc files produce .o files in the case of the rts. Maybe it's missing a .hc.o rule or something, so I tried to figure out the build system files but wasn't able to convince it to build the .hc files. I then emulated the gcc parameters used for other rts .c and .s files and compiled all the .hc files in the RTS myself. So I resume the make and it seems satisfied until it tries to build the rts in a different way (v, instead of l). Again, I compile all the .hc files by hand, and set the make on its merry way again.

Now I run into my real problem. It goes to build genprimopcode and doesn't know how to do it. I check utils/genprimopcode and indeed there are no .hc files in there. I jump back to my other tree (the one that produced the .hc files) and manually (guessing on the ghc command-line) ask it to produce all the .hc files for me, first calling alex and happy for the grammar. I copy these .hc files over and resume the build. It happily accepts my .hc files, but then when it goes to link genprimopcode, I get a ''massive'' list of missing symbols. These included things like:
{{{
_base_GHCziShow_showSignedInt1_closure
_stg_CAF_BLACKHOLE_info
_integerzmgmp_GHCziIntegerziType_Szh_static_info
}}}
So this seems to imply that it's trying to build an executable for genprimopcode, and it wants the rts (surprise), base, and integer-gmp linked to it. However, the command-line used to link genprimopcode is:
{{{
""gcc"" -o utils/genprimopcode/dist/build/tmp/genprimopcode  -O -m64 -g -O0 -DNO_REGS -DUSE_MINIINTERPRETER            utils/genprimopcode/dist/build/Lexer.o utils/genprimopcode/dist/build/Main.o utils/genprimopcode/dist/build/ParserM.o utils/genprimopcode/dist/build/Parser.o utils/genprimopcode/dist/build/Syntax.o 
}}}
... no linker flags at all, beyond the .o files! I'm not sure how this is supposed to ever link correctly with no rts or libraries. So I take that command-line for gcc and add to it from my 64-bit build tree until I get it to link (it ended up being a massive command-line, so I won't include it here). My built `genprimopcode` seemed to work, and displayed the help message when I ran it, but when I actually piped real primop specs into it, it segfaulted (in iconv, somehow).

I gave up on making my own `genprimopcode`, and under the assumption that it wasn't excessively platform-dependent, I asked someone to give me the various `genprimopcode` from their linux x86_64 platform. This may have been misguided but I don't know enough about the process to know better. Anyway, with these files, it gave up on trying to build `genprimopcode` and went along happily through the build.

In the final linkage step for stage2, producing the final ghc binary, I got another massive linker error. Again, I tinkered with its command-line until I got it to link correctly (lots of strange things missing there too, including the `PrelIOUtils.o` which I had to link in myself for some reason, and something defining `__hscore_long_path_size`, which I wrote a simple c file for). 

So anyway, the resulting ghc, somewhat unsurprisingly, segfaulted immediately (in Data.List.last, for what it's worth). `ghc +RTS --info` did work however, and printed out the expected stuff, so not everything was broken.

So anyway, I'm sorry for this rambling ""bug report"" but I'm not sure what to do, and I've been through the above process (with minor variations and experiments) about 5 times so far, so I'm pretty sure I'm following the instructions correctly.",pumpkin
3,4370,262,"giorgidze@…, ganesh, ezyang@…, jeroen.weijers@…, bos@…, mail@…, sebf@…, gideon@…, tyler@…, pumpkingod@…, leather@…, anton.nik@…, alex@…",Bring back monad comprehensions,Compiler,6.12.3,_|_,,new,normal,2013-06-03T00:29:25-0700,"George Giorgidze writes: My colleagues and I are working on Haskell [http://www-db.informatik.uni-tuebingen.de/files/weijers/IFL2010complete.pdf embedded DSL for data-intensive and data-parallel applications]. The idea is to provide the Haskell list prelude combinators to manipulate database-resident data. The combinators are not executed in Haskell runtime, instead they are compiled down to SQL, executed on relational database systems and the results are marshalled back to Haskell for further in-heap processing or generation of new database-able embedded programs.

Although programming with the standard list processing combinators is feasible, the embedded programs are much more concisely formulated using the list comprehension notation, especially, when extended with [http://research.microsoft.com/en-us/um/people/simonpj/papers/list-comp/ 'order by' and 'group by' constructs].

Unfortunately, in Haskell, the list comprehension notation is only available for processing lists.

In order to support the list comprehension notation, we have built a quasiquter that desugars the list comprehension notation, but, instead of generating code using the Haskell list prelude combinators the quasiquter generates code that uses list processing combinators from our embedded language.

Although the quasiquoting approach worked for us, it has a number of
drawbacks:

  * Introduces extra syntactic noise
  * Error messages are hard to understand as they refer to enerated code
  * Needs to be re-implemented for every list-based embedded language

One way to address the aforementioned drawbacks is to define our queries as a monad (similar to list monad) and use the monad comprehension notation. The do notation can be used but it is less suited for query languages.

Unfortunately monad comprehensions were removed from Haskell, prior to Haskell 98. However, I think that the notation is extremely useful not only for lists, but for other list like data structures, list-based query languages (see above), maybe even for wider range of EDSLs and monads. I think the feature deserves to be supported at least as a GHC language extension.

Thus, I would like to propose to design and implement the monad comprehension notation as a GHC language extension. I am willing to invest some time and contribute to this effort.

One can also look at how recently introduced 'order by' and 'group by'
constructs generalise to monad comprehensions. If that works, one could implement even more ""stylish"" monad comprehension notation.

Feedback from GHC users and developers would be very much appreciated.

  * Do you think that this is a good idea?

  * Would you use monad comprehensions (if available) for your
    library/EDSL/application?

  * Do you think that it would be hard to integrate this extension into
    current GHC codebase?
   
  * Have you already thought about how to generalise 'order by' and 'group by' to monad comprehensions?

  * Have you already thought about how to address the original objections to the monad comprehension notation?


",simonpj
2,3927,240,"pumpkingod@…, ppremont@…, conal@…, sjoerd@…, nathanhowell@…, eir@…, ghartshaw@…, jeroen.weijers@…, wren@…, hackage.haskell.org@…",Incomplete/overlapped pattern warnings + GADTs = inadequate,Compiler,6.12.1,7.8.1,simonpj,new,high,2013-03-22T03:19:00-0700,"Consider these defintions
{{{
data T a where
  T1 :: T Int
  T2 :: T Bool

-- f1 should be exhaustive
f1 :: T a -> T a -> Bool
f1 T1 T1 = True
f1 T2 T2 = False

-- f2 is exhaustive too, even more obviously
f2 :: T a -> T a -> Bool
f2 T1 (T1 :: T Int) = True
f2 T2 (T2 :: T Bool) = False

-- f3's first equation is unreachable
f3 :: T a -> T a -> Bool
f3 T2 T1 = False
f3 _  _  = True 
}}}
With HEAD (GHC 6.13) we get
{{{
G1.hs:11:1:
    Warning: Pattern match(es) are non-exhaustive
             In the definition of `f1':
                 Patterns not matched:
                     T1 T2
                     T2 T1
}}}
This is wrong.  
 * `f1` should behave like `f2`, and be accepted without warning.
 * `f3` has an inaccessible branch that is not reported.

The type checker accepts just the right programs, but the rather simple-minded approach to overlap warnings isn't doing the right thing.  

Note to self: the reason is that `tcPat` does not insert a coercion on the second arg to narrow the type, because there's no ''type'' reason to do so.  So for `f1` we get
{{{
f1 a (x:T a) (y:T a)
  = case x of { T1 (cox:a~Int) ->
      case y of { T1 (coy:a~Int) -> ... }
}}}
In the inner case it's not obvious that T2 is inaccessible.  If we refined eagerly we might get
{{{
f1 a (x:T a) (y:T a)
  = case x of { T1 (cox:a~Int) ->
      case (y |> T cox) of { T1 (coy:Int~Int) -> ... }
}}}
and now the scrutinee of the inner case has type `(T Int)` and the `T2` constructor obviously can't occur.

Fix this with the new inference engine.",simonpj
3,5289,227,"pho@…, v.dijk.bas@…, vandijk.roel@…, ivan.stojic@…, howard_b_golden@…, echo@…, hartmut0407@…, rian@…, wren@…, leather@…",Can't use ghci with a library linked against libstdc++,GHCi,7.0.3,7.6.2,,new,normal,2012-09-12T04:12:02-0700,"My `double-conversion` library links to a C++ library. If I build it and try to use it from `ghci`, I get a failure:

{{{

Prelude Data.Double.Conversion.Text Data.Text> :m +Data.Double.Conversion.Text Data.Text
Prelude Data.Double.Conversion.Text Data.Text> 
Leaving GHCi.
~ $ ghci
GHCi, version 7.0.2: 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> :m +Data.Double.Conversion.Text Data.Text
Prelude Data.Double.Conversion.Text Data.Text> toShortest 3
Loading package double-conversion-0.2.0.0 ... can't load .so/.DLL for: stdc++ (libstdc++.so: cannot open shared object file: No such file or directory)
}}}

I can sort of work around this, but then I get a different crash:

{{{
~ $ ln -s /usr/lib64/libstdc++.so.6 libstdc++.so
~ $ LD_LIBRARY_PATH=$(pwd) ghci
GHCi, version 7.0.2: http://www.haskell.org/ghc/  :? for help
Prelude> :m +Data.Double.Conversion.Text Data.Text
Prelude Data.Double.Conversion.Text Data.Text> toShortest 3
Loading package double-conversion-0.2.0.0 ... linking ... done.
""Floating point exception (core dumped)
}}}

Unfortunately, `gdb` doesn't give me a useful stack trace from this :-(",bos
2,5539,224,"johan.tibell@…, chowells79@…, bgamari@…, pho@…, rl, bos@…, alexey.skladnoy@…, choener@…, aruiz@…, idhameed@…, hackage.haskell.org@…",GHC panic -  Simplifier ticks exhausted,Compiler,7.3,7.6.2,simonpj,new,high,2013-03-22T03:27:54-0700,"When trying to install `blaze-builder` with a freshly installed GHC 7.3.20111007 linux/amd64 build, the following panic occurs:

{{{
$ cabal install  blaze-builder
Resolving dependencies...
Configuring blaze-builder-0.3.0.1...
Building blaze-builder-0.3.0.1...
Preprocessing library blaze-builder-0.3.0.1...
...
[10 of 13] Compiling Blaze.ByteString.Builder.HTTP ( Blaze/ByteString/Builder/HTTP.hs, dist/build/Blaze/ByteString/Builder/HTTP.o )
[11 of 13] Compiling Blaze.ByteString.Builder.Int ( Blaze/ByteString/Builder/Int.hs, dist/build/Blaze/ByteString/Builder/Int.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.3.20111007 for x86_64-unknown-linux):
	Simplifier ticks exhausted
    When trying UnfoldingDone a_s9oE{v} [lid]
    To increase the limit, use -fsimpl-tick-factor=N (default 100)
    If you need to do this, let GHC HQ know, and what factor you needed
    To see detailed counts use -ddump-simpl-stats
    Total ticks: 5123

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}",hvr
3,3693,216,"mihai.maruseac@…, pumpkingod@…, lonetiger@…, hackage.haskell.org@…, anton.nik@…, dterei, bgamari@…, scpmw@…, yi.codeplayer@…, nathanhowell@…",Show stack traces,Runtime System,6.10.4,7.6.2,,new,normal,2013-01-20T17:23:48-0800,"Debugging stack overflows can be very difficult, because GHC gives very little information as to exactly what is overflowing. Showing a basic stack dump (on crash, or in the ghci debugger) would be enormously helpful.

(Entered after spending two days trying to determine the cause of a stack overflow, before discovering it was a GHC bug [3677], which would have been apparent immediately if I could have only seen a callstack.)
",jpet
3,4259,213,"dimitris@…, v.dijk.bas@…, pumpkingod@…, nathanhowell@…, choener@…, shane@…, eir@…, hackage.haskell.org@…, andy.adamsmoran@…",Relax restrictions on type family instance overlap,Compiler (Type checker),6.12.1,7.8.1,,new,normal,2013-04-04T10:06:11-0700,"The following reduced fragment of some real code is rejected, but could be accepted, by GHC:

{{{
{-# LANGUAGE TypeFamilies, EmptyDataDecls #-}
data True

type family LessEq a b :: *
type instance LessEq a a = True
type instance LessEq (f a) (f b) = LessEq a b
}}}

GHC says:

{{{
    Conflicting family instance declarations:
      type instance LessEq a a
        -- Defined at /home/richards/.random/tf.hs:5:14-19
      type instance LessEq (f a) (f b)
        -- Defined at /home/richards/.random/tf.hs:6:14-19
}}}

This is entirely in line with the documentation, which requires the RHS to be structurally equivalent in the case of overlap. However, this rule is too restrictive. In the absence of -XUndecidableInstances, neither termination nor soundness would be sacrificed if the rule were relaxed to require extensional equality /after/ expanding the types as far as possible.

In particular (absent -XUndecidableInstances), such an expansion must terminate for the same reason that type families terminate in general. For soundness, suppose the resulting system is unsound, and consider the smallest type family application which has two possible distinct expanded types. We know the RHS of those types are equal after a partial expansion of only smaller (hence sound by minimality) type family applications, resulting in a contradiction.

In order to retain soundness in the presence of -XUndecidableInstances, any pair of type instances, where either instance could not be compiled without -XUndecidableInstances, would continue to use the current syntactic equality rule.",lilac
3,1349,207,"id@…, pho@…, bos@…, johan.tibell@…, kolmodin@…, slyfox@…, coreyoconnor@…, illissius@…, hackage.haskell.org@…","Generalise the ! and UNPACK mechanism for data types, to unpack function arguments",Compiler,6.6.1,7.6.2,,new,normal,2013-01-31T20:59:04-0800,"See this thread:
   http://www.nabble.com/More-speed-please!-t3411977.html

Briefly the idea is to allow
{{{
  data T = MkT (!Int -> Bool)
}}}
to make a `MkT` hold strict functions only.  Anyone unpacking a `MkT` can assume the function is strict; and anyone building a `MkT` gets a strictness wrapper aound whatever function they supply, so even if they supply a lazy function, it's made strict.

Seems like a natural generalisation of the existing strictness and UNPACK mechanism for data types.

Lots of details in the thread above.

Simon",simonpj
2,5218,206,"johan.tibell@…, dons, dcoutts, pho@…, lykahb@…, reiner.pope@…, alexey.skladnoy@…, wren@…, patrick@…, hackage.haskell.org@…",Add unpackCStringLen# to create Strings from string literals,Compiler,7.0.3,7.8.1,igloo,new,high,2013-03-22T03:22:03-0700,"GHC insert calls to `unpackCString#` to convert string literals to `String`s. Libraries like bytestring use rewrite rules to match on this call to optimize code like `pack (unpackCString# s)`.

If GHC would instead use a version of unpackCString#, say unpackCStringLen#, that includes the (statically known) length, creating `ByteString`s from literals could be a constant time operation instead of a linear time operation.

Another use case, which motivated this ticket, is appending string literals to builders (e.g. using `Data.Binary.Builder.fromByteString`). For small strings the most efficient way to append a string to the builder is to copy the statically allocated string directly into the builder's output buffer. If the string length was known statically, we could do this efficiently using `memcpy` or even using a small unrolled loop.
",tibbe
3,6018,201,"simonpj@…, mokus@…, eir@…, nathanhowell@…, nfrisby, conal@…, shane@…, andy.adamsmoran@…, byorgey@…, Artyom.Kazak@…",Injective type families,Compiler,7.4.1,7.8.1,simonpj,new,normal,2013-06-17T09:57:42-0700,"Injective type families have been discussed several times on the mailing list and identified as a potentially useful feature.

I've naively attempted a proof-of-concept in GHC. It's almost certainly incorrect and probably breaks the type system, but I thought it best to put it here and see if it can be made workable.

In summary, my changes are:

  * Add a new keyword, {{{injective}}}, which is available only when the {{{TypeFamilies}}} extension is enabled. Injective families may then be defined thus:

    {{{
  injective family F a :: *
  type instance F Int  = Bool
  type instance F Bool = Int

  injective family G a :: *
  type instance G a = a
    }}}

  Syntax is of course completely changeable; I've simply picked one of the possible designs. Hopefully this won't be subjected to too much bike-shedding.

  * Add the constructor {{{InjFamilyTyCon}}} to {{{TyConRhs}}} and the family flavour {{{InjectiveFamily}}} to {{{HsSyn}}}. Again, I've opted to encode injectivity as a flavour rather than (say) a {{{Bool}}} attached to type families. This is a completely arbitrary choice and may be utterly stupid.

  * Altered the definition of decomposable {{{TyCon}}}s to include injective families ({{{isDecomposableTyCon}}}). This effectively introduces a typing rule that says if we have {{{(F a ~ F b)}}} then we can deduce {{{(a ~ b)}}} ({{{TcCanonical}}}).

  * Modified the unifier so that it will attempt to replace saturated injective families with their left-hand sides where possible ({{{TcUnify}}}). This means that in a function such as:

    {{{
  f :: F a -> F a
  f = ...
    }}}

  The type of {{{f False}}} is inferred as {{{F Int}}} (i.e., {{{a}}} is no longer ambiguous).

Some things work, some things don't. For example, the attached file typechecks, but if I actually try to evaluate {{{f False}}} I get nothing (not even a Segmentation fault).

See what you think.
  ",lunaris
3,849,175,"pho@…, johan.tibell@…, claus, daniel.is.fischer@…, michal.terepeta@…, ikke+ghc@…, buecking@…, hackage.haskell.org@…",Offer control over branch prediction,Compiler,6.4.2,7.6.2,,new,normal,2013-03-25T04:26:14-0700,"So now that GHC is so good at producing really fast low level code (see
ByteString benchmarks) we start to encounter low level gubbins where to
get the fastest possible code we need slightly more influence over
branch prediction.

In the code for ByteString's 'writeStrUp/Dn' functions we're doing a
tight loop writing bytes to memory.

The first version looks much like this:
{{{
loop fp n off s = case next s of
    Done       -> return $! PS fp 0 off
    Skip    s' -> loop fp n off s'
    Yield x s' -> do
             withForeignPtr fp $ \p -> pokeByteOff p off x
             loop fp n (off+1) s'
}}}
When we get to the end of a memory block we need to double the size of
the memory block and carry on. So this adds an additional conditional
test into this loop.
{{{
loop fp n off s = case next s of
    Done       -> trimUp fp n off
    Skip    s' -> loop fp n off s'
    Yield x s'
        | n == off -> realloc fp n off s' x
        | otherwise -> do
             withForeignPtr fp $ \p -> pokeByteOff p off x
             loop fp n (off+1) s'
}}}
There are dramatic differences between equivalent forms of code. Just by
reversing the order of the (n==off) test one form I can process 50Mb of
data in 0.20 seconds and in the other it takes 0.34 seconds.

That is:
{{{
        | n == off -> realloc fp n off s' x
        | otherwise -> do ...
}}}
vs
{{{
        | n /= off -> do ...
        | otherwise -> realloc fp n off s' x
}}}
I think that this is all down to branch prediction and the arrangement
of basic blocks. On a modern CPU correctly predicted branches are nearly
free while mis-predicted branches are very costly due to stalled
pipelines etc.

In gcc they have a branch prediction framework. It annotates
conditionals with prediction information. It then uses that during code
generation to do things like arranging basic blocks so that unlikely
blocks are moved out of line. It gets the prediction information from a
few sources. One is a simple static branch predictor, for example
branches back to to the beginning of a loop are likely to be taken and
branches to error functions are not. gcc even has a profile feedback
system to find the real probabilities of branches from a sample run of
the program. It also has a user annotation {{{__builtin_expect()}}} which many
C projects use in the form of a macro:
{{{
if (unlikely(x==0)) { ...
}}}
The Linux kernel uses this fairly heavily to move error handling code
out of the main 'fast path' code.


Anyway, so what I wish is that I could write something like:
{{{
loop fp n off s = case next s of
    Done       -> {-# UNLIKELY #-}
                  trimUp fp n off
    Skip    s' -> loop fp n off s'
    Yield x s'
        | n == off -> {-# UNLIKELY #-}
                      realloc fp n off s' x
        | otherwise -> do
             withForeignPtr fp $ \p -> pokeByteOff p off x
             loop fp n (off+1) s'
}}}
The best approximating effect that I can use at the moment is to make
the unlikely realloc branch a local function in a where clause but mark
it with {{{ {-# NOINLINE #-} }}} so that the code for the realloc case doesn't
pollute the tight loop for the normal fast case. Then the other
approximation is fiddling with the logic of the binary test and looking
at the benchmarks. The combination of these two techniques makes a
dramatic difference to the speed.

However I do need more control to do it reliably, while I was able to
make it work for writeStrUp, I could not find a combination to work for
writeStrDn - we loose about 50% performance when we add the realloc
branch. So a slightly more reliable method to hint at the likelihood of
conditionals would make this kind of low level code faster and easier to
write.

Some time ago as a quick hack I did add a branch prediction annotation
to the CMM conditional constructor. I only used it in the C backend to
turn it into uses of gcc's {{{__builtin_expect()}}}. I also didn't connect it
to the front end so I didn't have any high level static branch
prediction (which could be done by looking for branches with recursive
calls or calls to error etc). The only place I did actually use it was
in the heap check and stack check. I assumed that it would be
advantageous to predict heap and stack overflow branches as not taken.
It was only a quick hack - I didn't do any benchmarks to see if it had
any effect.


Anyway, just a thought, and of course not something we should be
thinking about 'til post 6.6.

Duncan",simonpj
1,2451,166,"pho@…, bos@…, tibbe, anton.nik@…, phunge0@…, leuschner@…, william.knop.nospam@…, lewurm@…",New signal-handling API,libraries/unix,6.8.3,7.8.1,simonmar,new,highest,2012-11-01T05:33:13-0700,"The current API for handling signals in `System.Posix` is lacking in a couple of ways:

 * it isn't modular: there's no way for a library to install a private signal handler,
   there is only a singla global handler per signal.

 * it isn't possible to get hold of the information from `siginfo_t` (#592).

I want to propose a new API.  This has already undergone a round of changes after discussion with Duncan Coutts, and we ended up with something quite simple.  Haddock docs are here:

[http://www.haskell.org/~simonmar/unix/System-Posix-Signals.html#4]

(also attached as `unix-html.tar.gz`).

I have working patches to implement this.  The old API is still available, and is reimplemented using the new API.  Signal handlers installed using the old API will coexist with those installed using the new API.

The main motivation for this change was so that I could hook the `SIGCHLD` signal in the `System.Process` library without disturbing users of the `System.Posix` library who might also want to install a `SIGCHLD` handler.

Deadline: 1 Aug (2 weeks)

",simonmar
3,7850,166,"Artyom.Kazak@…, the.dead.shall.rise@…, matvey.aksenov+ghctrac@…, simonmar, carter.schonwald@…, pho@…, anton.nik@…",Strangely high memory usage on optimized Ackermann function,Compiler,7.6.2,7.6.3,,merge,normal,2013-06-08T15:40:34-0700,"Greetings.

The following post on stack overflow demonstrates some strange behavior in, at least, recent GHC versions (7.4.2 on):

[http://stackoverflow.com/questions/16115815/ackermann-very-inefficient-with-haskell-ghc]

The program in question is simple:

{{{
main = print $ ack 4 1

ack :: Int -> Int -> Int
ack 0 !n = n+1
ack m  0 = ack (m-1) 1
ack m  n = ack (m-1) $ ack m (n-1)
}}}

Here are the properties I've been able to deduce so far:

1) When compiled without optimizations, the program uses almost no memory, but of course takes a while.

2) When compiled with optimizations (-O and above), the program eats memory at a staggering rate. It easily freezes my machine in a matter of seconds.

3) -ddump-simpl reveals that the loop is completely unboxed, operating only on Int#. -ddump-prep also shows no lets where allocation would presumably happen.

4) Setting a maximum heap size typically seems to have no effect. When I set it to the minimum heap size with -M4096, even the optimized program seems to run in constant space most of the time. However, using something like -M1000000 seems to result in the outrageous memory usage, and the RTS never catches that far more than 1 megabyte of memory is being used. I had to convince myself that the flag actually does something with another test program.

5) The standard bounded stack also does nothing.

So, we seem to have a program that is allocating vast amounts of (ostensibly) non-heap, non-stack memory; but only when optimized.

I believe I once set the maximum heap to 40960B, and killed the program before it killed my machine. On exiting, I got a heap overflow error. So, my initial stab would be that the completely unboxed loop somehow ''is'' allocating in the heap, but somehow not in a way that ever allows the garbage collector or heap overflow check to run (similar to how a non-allocating loop can block any thread preemption). That's a wild guess, though.

I'm unable to easily investigate the behavior on older GHC versions, unfortunately. So I'm unsure how far back this behavior goes. If I've missed something obvious, I apologize, but this seems like very odd behavior to me.",dolio
3,4295,163,"nicolas.pouillard@…, v.dijk.bas@…, hackage.haskell.org@…, favonia@…, nathanhowell@…, rabeslik@…, ben@…",Review higher-rank and impredicative types,Compiler,6.12.3,7.6.2,simonpj,new,normal,2012-09-12T04:11:59-0700,"The ticket is a placeholder to remind me to work through the test cases for impredicative and higher rank types in the new typechecker.  For now, I'm marking many of them as `expect_broken` on this ticket, although I think many of them really should fail.
 * tc150
 * tc194
 * tcfail198
 * tcfail174
 * tcfail165
 * tcfail145
 * tcfail104
 * tc211
 * indexed-types/should_compile/T4120
 * simpl017
 * Many tests in `boxy/` (see also #1330 for Church2)
 * #2193
 * #2846
 * #4347
 * [http://augustss.blogspot.com/2011/07/impredicative-polymorphism-use-case-in.html Lennart's blog post] has an interesting use case of impredicative polymorphism; it worked in 7.0, but alas not in the new typechecker.
",simonpj
3,888,162,"Bulat.Ziganshin@…, johan.tibell@…, hackage.haskell.org@…, reiner.pope@…, Jake.McArthur@…, choener@…, dterei",Implement the static argument transformation,Compiler,6.4.2,7.6.2,,new,normal,2012-09-12T04:11:56-0700,"The Static Argument transformation optimises
{{{ 
  f x y = ....f x' y...
}}}
into 
{{{
  f x y = let g x = ....g x'...
          in g x
}}}
Instead of passing {{{y}}} along unchanged, we make it into a free variable of a local function definition {{{g}}}.  

Unfortunately, it's not always a win.  Andre Santos gives a discussion, and quite a few numbers in [http://research.microsoft.com/%7Esimonpj/Papers/santos-thesis.ps.gz his thesis].

But sometimes it is a pretty big win.  Here's the example that recently motivated me, which Roman Leshchinskiy showed me.  You need the attached file Stream.hs, and then try compiling
{{{
  import Stream
  foo :: (a -> b) -> [a] -> [c]
  foo f = mapL f
}}}

Thus inspired, I think I have a set of criteria that would make the static arg transformation into a guaranteed win:
 
 * there is only one (external) call to the function
 * OR its RHS is small enough to inline
 * OR it is marked INLINE (?)

So I'd like to try this idea out.",simonpj
5,2289,156,"dons@…, johan.tibell@…, michal.terepeta@…, tkn.akio@…, jwlato@…, alpmestan@…, hackage.haskell.org@…",Needless reboxing of values when returning from a tight loop,Compiler,6.8.2,7.6.2,,new,lowest,2013-01-31T21:03:04-0800,"GHC wants to box up strict values when returning from tight inner loops, even when they're
immediately taken apart. This leads to redundant instructions in the bodies of tight loops,
and more code. 

It affects, in particular, loops that result from fusion, which need to be tight, but often return multiple values via unlifted pairs.

Consider this program:

{{{
{-# OPTIONS -fexcess-precision #-}
{-# LANGUAGE TypeOperators #-}

import System.Environment
import Text.Printf
import Data.Array.Vector

mean :: UArr Double -> Double
mean arr = s / fromIntegral l
  where
    s :*: l = foldlU k (0 :*: 0) arr :: (Double :*: Int)
    k (s :*: n) x = s+x :*: n+1

main = do
    [d] <- map read `fmap` getArgs
    printf ""%f\n"" (mean (enumFromToFracU 1 d))
}}}

It generates this rather good Core (ghc 6.8.2):

{{{
$s$wfold_s1rB :: Double#
               -> Int#
               -> Double#
               -> (# Double, Int #)

$s$wfold_s1rB =
\ (sc_s1rr :: Double#)
  (sc1_s1rs :: Int#)
  (sc2_s1rt :: Double#) ->
  case >## sc_s1rr y_a1pr of wild4_X1no {
    False ->
      $s$wfold_s1rB
        (+## sc_s1rr 1.0)
        (+# sc1_s1rs 1)
        (+## sc2_s1rt sc_s1rr);
    True -> (# D# sc2_s1rt, I# sc1_s1rs #)
  };
} in 
case $s$wfold_s1rB 2.0 1 1.0 of ww_s1qg { (# ww1_s1qi, ww2_s1qj #) ->
case ww1_s1qi of wild4_a1mC { D# x_a1mE ->
case ww2_s1qj of wild5_aP6 { I# x1_aP8 ->
case /## x_a1mE (int2Double# x1_aP8)
of wild21_a1mK { __DEFAULT ->
D# wild21_a1mK
}}}

But note, what's this?

{{{
    True -> (# D# sc2_s1rt, I# sc1_s1rs #)
  };
} in 
case $s$wfold_s1rB 2.0 1 1.0 of ww_s1qg { (# ww1_s1qi, ww2_s1qj #) ->
case ww1_s1qi of wild4_a1mC { D# x_a1mE ->
case ww2_s1qj of wild5_aP6 { I# x1_aP8 ->
case /## x_a1mE (int2Double# x1_aP8)

}}}

The return values of what was a strict pair are boxed, placed in an unboxed tuple,
and then immediately unboxed and the division takes place.

Ok, let's isolate this. Here, the boxed return, from the inner loop:

{{{
mean_s19V :: Double#
           -> Int#
           -> Double#
           -> (# Double, Int #)

mean_s19V =
\ (ds1_dD3 :: Double#)
  (ds2_dD4 :: Int#)
  (ds3_dD5 :: Double#) ->
  case >## ds1_dD3 d#_aoG of wild4_Xw {
    False ->
      mean_s19V
        (+## ds1_dD3 1.0)
        (+# ds2_dD4 1)
        (+## ds3_dD5 ds1_dD3);
    True -> (# D# ds3_dD5, I# ds2_dD4 #)
  };
} in 
case mean_s19V 2.0 1 1.0 of wild4_Xr { (# ds1_dCV, ds2_dCW #) ->
case ds1_dCV of wild5_Xv { D# x_aoR ->
case ds2_dCW of wild6_Xy { I# y_aoS ->
case /## x_aoR (int2Double# y_aoS) of wild7_XB { __DEFAULT ->
D# wild7_XB
}}}

And the inner loop and exit:

{{{
s1bd_info:

  -- what's this stuff?
  leaq        32(%r12), %rax
  cmpq        %r15, %rax
  movq        %rax, %r12
  ja  .L17

  -- ok, to business:
  ucomisd     5(%rbx), %xmm5
  ja  .L19
  movapd      %xmm6, %xmm0
  leaq        -32(%rax), %r12
  incq        %rsi
  addsd       %xmm5, %xmm0
  addsd       .LC1(%rip), %xmm5
  movapd      %xmm0, %xmm6
  jmp s1bd_info


.L19:
  movq        %rsi, -16(%rax)
  movq        $base_GHCziBase_Izh_con_info, -24(%rax)
  movq        $base_GHCziFloat_Dzh_con_info, -8(%rax)
  movsd       %xmm6, (%rax)
  leaq        -7(%rax), %rbx
  leaq        -23(%rax), %rsi
  jmp *(%rbp)
}}}

Now, I can avoid the reboxing manually:

{{{
mean_s19R :: Double#
           -> Int#
           -> Double#
           -> (# Double#, Int# #)

mean_s19R =
\ (ds1_dCZ :: Double#)
  (ds2_dD0 :: Int#)
  (ds3_dD1 :: Double#) ->
  case >## ds1_dCZ d#_aoG of wild4_Xw {
    False ->
      mean_s19R
        (+## ds1_dCZ 1.0)
        (+# ds2_dD0 1)
        (+## ds3_dD1 ds1_dCZ);
    True -> (# ds3_dD1, ds2_dD0 #)
  };
} in 
case mean_s19R 2.0 1 1.0 of wild4_Xr { (# x_aoR, y_aoS #) ->
case /## x_aoR (int2Double# y_aoS) of wild5_Xv { __DEFAULT ->
D# wild5_Xv
}}}

And we get:

{{{
s1b9_info:
  -- hey , our junk is gone!

  ucomisd     5(%rbx), %xmm5
  ja  .L17
  movapd      %xmm6, %xmm0
  incq        %rsi
  addsd       %xmm5, %xmm0
  addsd       .LC1(%rip), %xmm5
  movapd      %xmm0, %xmm6
  jmp s1b9_info

-- cool, that was it, let's go home:
.L17:
  movapd      %xmm6, %xmm5
  movq        %rsi, %rbx
  jmp *(%rbp)

}}}

Which is a much better result. The loop is tighter.

What can be done here?",dons
3,1475,152,"ganesh.sittampalam@…, alfonso.acosta@…, mjm2002@…, Deewiant, merehap, ivan.perez@…, hackage.haskell.org@…",Adding imports and exports with Template Haskell,Template Haskell,6.8.2,_|_,,new,normal,2013-03-25T04:07:35-0700,"(wished for by Adrian Hey in http://www.haskell.org/pipermail/template-haskell/2007-June/000598.html)

It would be useful to be able to add module exports with TH, although I'm not sure exactly how it would be done. Perhaps something like
{{{
$( do n <- newName ""foo""
      let d = funD n ...
      addExport (varE n)
      return [d]
}}}
but at the point we call `addExport` the typechecker doesn't know that there will be a declaration for the name.

Less useful, as TH names include the package and module of the name's definition, is the ability to add module imports. However, this can still be used to get a kind of dynamic binding effect, either with `mkName`'s names or plain Haskell code, e.g.:
{{{
$( addImport (if ... then '''Data.ByteString else '''Data.ByteString.Lazy)
             (mkName ""BS"") )

foo :: BS.ByteString
foo = BS.append ...
}}}
(we'd actually probably want a datatype that mirrors Haskell import decls more closely).",igloo
3,3333,147,"ghc@…, hgolden, tkn.akio@…, chetant@…, chris@…, batterseapower@…, hvr@…, mail@…",GHCi doesn't load weak symbols,GHCi,6.10.4,7.6.2,,new,normal,2013-04-28T07:00:45-0700,"GHCi fails to load modules with weak symbols.  The compiler, in contrast, has no trouble with them.  The attached Cabal package demonstrates the problem.  After building and installing:

{{{
:Prelude> :m +WeakTest
Prelude WeakTest> weak_test 0
Loading package WeakTest-0 ... linking ... <interactive>: /home/heatsink/.cabal/lib/WeakTest-0/ghc-6.10.3/HSWeakTest-0.o: unknown symbol `weak_test'
}}}

I encountered this problem while trying to build a package that contains C++ code.  Because GCC generates weak symbols when compiling C++, libraries that contain C++ code will not work in GHCi.  (Granted, this is not the only problem with mixing C++ and Haskell.)",heatsink
3,7633,147,"eir@…, byorgey@…, daniel@…, hvr@…, ghc@…, martijn@…, bgamari@…","Checkable ""minimal complete definitions""",Compiler,7.6.1,7.8.1,,new,normal,2013-06-08T13:23:16-0700,"#6028 suggested warning on cyclic unimplemented defaults. This doesn't work for the reasons mentioned there, among others (also e.g. [http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/Control-Applicative.html#g:2 `Alternative`] has mutually recursive `some` and `many` methods, which shouldn't be warned about). Figuring out when to warn automatically seems hard.

But Haskell already has an ad-hoc mechanism for specifying which methods need to be implemented: A ""minimal complete definition"" specified in the comments of almost every class definition that has optional methods. Unfortunately comments are aren't compiler-checked. It seems that the simplest solution would be to specify these in a way that the compiler can understand.

The obvious approach is to add a pragma for it in the class definition. In particular, one could write a pragma for each ""minimal set"" of definitions, and the compiler could warn if none of them are implemented (and suggest which methods to implement). This lets us keep the convenience of default method implementations without losing safety. Without any pragmas, the compiler could fall back to the set ""all methods without defaults"", which is what it uses now.

It might look something like this:

{{{
class Functor m => Monad m where
  return :: a -> m a

  (>>=) :: m a -> (a -> m b) -> m b
  m >>= f = join (fmap f m)

  join :: m (m a) -> m a
  join m = m >>= id

  {-# MINIMAL return, join #-}
  {-# MINIMAL return, (>>=) #-}

class Eq a where
  (==), (/=) :: a -> a -> Bool
  x == y = not (x /= y)
  x /= y = not (x == y)
  {-# MINIMAL (==) #-}
  {-# MINIMAL (/=) #-}
}}}",shachaf
3,910,138,"bos, hackage.haskell.org@…, dterei, idhameed@…, mail@…, jan.stolarek@…, rrnewton@…, chetant@…",--make should have a -j flag for parallel building,Compiler,6.4.2,_|_,,new,normal,2013-06-03T14:19:02-0700,"It should be possible to give --make a -j flag, similar to make's, to tell it to
use multiple proceses to build modules. This would allow executables, libraries
and cabal packages to be built faster for people with multiple CPUs.",igloo
4,4081,137,"benl@…, nightski@…, bjornbm, chr.andreetta@…, choener@…, batterseapower, rl, bgamari@…",Strict constructor fields inspected in loop,Compiler,6.13,7.6.2,benl,new,low,2013-03-05T12:04:31-0800,"Here is a small example to illustrate the problem:

{{{
module T where

data S a b = S !a !b

class C a where
 make :: a -> S a a

instance C Int where
 {-# NOINLINE make #-}
 make n = S n n

foo :: (C a, Num a) => a -> Int -> a
{-# INLINE foo #-}
foo x k = k `seq` m `seq` go k 0
 where
   S m n = make x

   go 0 i = i
   go k i = go (k-1) (i + m)
}}}

{{{
module U where

import T

bar :: Int -> Int -> Int
bar s k = foo s k + 1
}}}

Relying on !LiberateCase seems to be the only way to unbox `m` outside of the loop in `bar`. The seq in `foo` doesn't help because it gets eliminated immediately.

GHC does have enough information to do this:

{{{
U.bar =
 \ (s_aaw [Dmd=Just S(A)] :: GHC.Types.Int)
   (k_aax [Dmd=Just U(L)] :: GHC.Types.Int) ->
   case k_aax
   of k1_ajh [Dmd=Just U(L)] { GHC.Types.I# ipv_ajj [Dmd=Just A] ->
   case T.$fCInt_$cmake s_aaw of _ { T.S m_ajy [Dmd=Just U(T)] _ ->
   ...
}}}

Note the demand on `m`. If it was an argument instead of a local binding, it would be unboxed by w/w.

Also, the seq does help if we use lazy pairs instead of strict ones.
",rl
2,4245,129,"william.knop.nospam@…, fryguybob@…, malicious.wizard@…, bos, mihai.maruseac@…, pho@…",ghci panic: thread blocked indefinitely in an MVar operation,GHCi,6.12.3,7.6.2,tibbe,new,high,2013-03-22T02:21:43-0700,"I stumbled across this error today:
{{{
phil ~
$ ghci
GHCi, version 6.12.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.
Loading package ffi-1.0 ... linking ... done.
Prelude> 
[1]+  Stopped                 ghci
phil ~
$ fg
ghci
^C^C

Prelude> 
ghc: panic! (the 'impossible' happened)
  (GHC version 6.12.3 for i386-apple-darwin):
	thread blocked indefinitely in an MVar operation

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

phil ~
$
}}}

Steps to reproduce:
 * start ghci
 * ctrl-z
 * fg
 * ctrl-c
 * ctrl-c
 * enter
 * wait ~2 seconds

I'm not sure if it is related but while waiting for the impossible to happen, any characters typed are not echoed to the screen.",pturnbull
5,2110,129,"rl, dimitris@…, ryani.spam@…, mail@…, sweirich@…, hackage.haskell.org@…",Rules to eliminate casted id's,Compiler,6.8.2,7.6.2,,new,lowest,2013-01-14T17:55:28-0800,"
Some people (e.g. jedbrown, who originally brought this up) have/use C libraries that deal with arrays of doubles (i.e. CDouble) that they would like to use from Haskell code, with the Double type (perhaps there are instances of some classes for Double, but not CDouble). In jedbrown's case he has a CArray datastructure that wraps the C array and is an instance of Haskell's IArray.

However, people doing this sort of thing tend to care a lot about performance, so don't want to spend O(n) time doing O(n) allocation. Thus the temptation is to make the assumption that CDouble == Double, and to create the `CArray i Double` directly.

The more correct way to do it would be to make a `CArray i CDouble` and then use `amap realToFrac` to convert it to a `CArray i Double`. However, I don't believe that GHC is currently smart enough to optimise away `amap realToFrac`.

Let's look at a simpler example:
{{{
cdoubles :: [CDouble]
cdoubles = read ""foo""

doubles :: [Double]
doubles = map realToFrac cdoubles
}}}
(here `map` is playing the role of `amap`). The core for this looks like (very simplified)
{{{
Q.a1 = \ (ds_aMc :: Foreign.C.Types.CDouble) -> ds_aMc
Q.doubles = GHC.Base.map (Q.a1 `cast` <mumble>) Q.cdoubles
}}}
It looks to me that if we could produce
{{{
Q.doubles = GHC.Base.map (id `cast` <mumble>) Q.cdoubles
}}}
instead then we might be able to have a rule
{{{
forall mumble . map (id `cast` mumble) = id `cast` mumble'
}}}
The major problem, as far as I can see, is how to construct the `mumble'`.

Does that sound plausible?
",igloo
3,4937,127,"johan.tibell@…, pumpkingod@…, as@…, michal.terepeta@…, dterei, hackage.haskell.org@…","Remove indirections caused by sum types, such as Maybe",Compiler,7.0.1,7.6.2,,new,normal,2013-01-31T23:41:10-0800,"While null pointers cause correctness issues in languages that allow them, they do have one benefit over `Maybe` when used to represent nullable values: they allow encoding the absence of a value cheaply. Using `Maybe` to represent a nullable value adds an extra indirection (pointer) to get to the wrapped value.

We could use the bits set by pointer tagging to encode that the pointer points directly to the value, rather than to an intermediate constructor. I believe JHC takes this approach.

A motivating example is this implementation of a hash array mapped trie (HAMT): A HAMT stores key/value pairs and subtrees in two arrays.

{{{
data Node k v = MkNode (Array (Maybe k)) (Array (Either v (Node k v))
}}}

Iff index `i` in the first array is `Nothing`, the second array contains a Node at index `i`, otherwise it contains a value.

Adding an extra indirection, using `Maybe` or `Either`, adds both space (in terms of extra points and data constructor headers) and time (in terms of additional cache misses and branches).
",tibbe
5,367,126,"ganesh.sittampalam@…, SamB, leon.p.smith@…, pho@…, bgamari@…, fryguybob@…",Infinite loops can hang Concurrent Haskell,Compiler,6.4.1,_|_,ezyang,new,lowest,2013-01-24T09:24:36-0800,"{{{
An infinite loop that does not allocate can hang 
Concurrent Haskell, becuase no thread switching 
occurs.  Demo code below (from Koen Claessen).

Bites occasionally, but not often.

Simon



module Main where

import Control.Concurrent
  ( forkIO
  , threadDelay
  , killThread
  , newEmptyMVar
  , takeMVar
  , putMVar
  )

import Data.IORef

import IO( hFlush, stdout )

timeout :: Int -> a -> IO (Maybe a)
timeout n x =
  do put ""Race starts ...""
     resV <- newEmptyMVar
     pidV <- newEmptyMVar

     let waitAndFail =
           do put ""Waiting ...""
              threadDelay n
              put ""Done waiting!""
              putMVar resV Nothing

         eval =
           do put ""Evaluating ...""
              x `seq` put ""Done!""
              putMVar resV (Just x)

     -- used ""mfix"" here before but got non-termination 
problems
     -- (not sure they had anything to do with mfix)
     pid1  <- forkIO $ do pid2 <- takeMVar pidV
                          eval
                          killThread pid2
     pid2  <- forkIO $ do waitAndFail
                          killThread pid1
     putMVar pidV pid2

     put ""Blocking ...""
     takeMVar resV

put s =
  do putStrLn s
     hFlush stdout

main =
  do timeout 1 (sum (repeat 1))
<<<

The above program produces the following (expected 
result):

>>>
Race starts ...
Blocking ...
Evaluating ...
Waiting ...
Done waiting!
<<<

If you replace 'sum (repeat 1)' by 'last (repeat 1)' the
program hangs.


}}}",simonpj
3,605,123,"Bulat.Ziganshin@…, id@…, pho@…, hackage.haskell.org@…, tibbe, dterei",Optimisation: strict enumerations,Compiler,None,_|_,,new,normal,2013-01-23T10:19:54-0800,"Strict enumeration types should be implemented by Int#, both in the strictness analyser and for constructor fields annotated with {-# UNPACK #-}.",simonmar
3,7346,121,"leather@…, hvr@…, v.dijk.bas@…, cgaebel@…, pho@…, carter.schonwald@…",Allow the use of `deriving` for GHC generics,Compiler,7.7,7.8.1,dreixel,new,normal,2013-04-12T09:14:32-0700,"Currently, a class that makes use of generic default methods (via the `DefaultSignatures`) extension can be instantiated by providing an empty instance declaration.

I propose to allow the use of `deriving` as well:

 1. Standalone deriving should be usable for a class not only for the specific set of classes supported by GHC now, but in addition for any class, if (
    * there's at least one generic default given for a method of the class, and
    * there are generic or normal default implementations for *all* methods of the class.

 There are a number of advantages of this solution over the empty instance declaration: we make it explicit that something generic is going on here; we ensure at compile time that we're not missing an implementation of a method; and we come syntactically closer to built-in derivable classes.

 In cases where a conflict arises between current GHC semantics and the proposed semantics (for example, when newtype-deriving is involved, I guess), I propose to stick with current GHC semantics, but I'm open for other suggestions.

 2. I'd also like for normal `deriving` to be useful under the same conditions as above. For normal `deriving` GHC has to figure out the class context automatically. I propose that if normal `deriving` is used, GHC uses the same heuristic for figuring out the class context that it uses for `Eq` in the case of `*`-kinded classes, and for `Functor` in the case of `* -> *`-kinded classes. That may not be optimal or even wrong. But in such cases, standalone deriving can still be used.",kosmikus
4,5296,119,"dsf@…, hackage.haskell.org@…, sweirich@…, mail@…, steven.keuchel@…",Add explicit type applications,Compiler (Type checker),7.0.3,7.6.2,,new,low,2013-06-18T03:00:13-0700,"This example is derived from code in my application.  It works, but I can't add a signature to it.  In other places it is preventing some code from compiling at all.

{{{
{-# LANGUAGE KindSignatures, MultiParamTypeClasses, RankNTypes #-}
{-# OPTIONS -Wall #-}
module Test where

class C t1 t2 m where method :: Int -> m t2

f :: forall t1 t2 (m :: * -> *). C t1 t2 m => Int -> m t2
f x = method x
}}}",dsf
3,4102,118,"josefs@…, gabriel@…, dterei, rrnewton@…, wren@…, johan.tibell@…",Bit manipulation built-ins,libraries/base,6.12.2,7.6.2,,new,normal,2012-09-12T04:11:59-0700,"So far Haskell/GHC lacks more HL bit manipulation instructions which on many platform can be compiled to single instruction. Probably the good guide are those implemented in LLVM:

 - byte swap
 - population count
 - number of leading zeros
 - number of trailing zeros

All of them can be implemented in terms of Data.Bits - however not quite in efficient way (like looping over patterns).",uzytkownik
3,4092,117,"daniel.is.fischer@…, midfield@…, dterei, iridcode@…, johan.tibell@…, acfoltzer@…",Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64#,Compiler,6.12.2,7.6.2,,new,normal,2012-09-12T04:11:59-0700,"There are currently two ways to compute the ulp of double numbers with GHC :
 * Calling a C function, which requires to allocate a pointer. This is way too expensive when using interval arithmetic (for instance), that compute two ULPs at each arithmetic operations.
 * Programming it by hand in haskell with GHC primitive operations, which requires using unsafeCoerce# : this does not work in GHC 6.12.2.

unsafeCoerce# should work, and there should be a primitive ulp# function in GHC, operating on Doubles at least.
 
By the way, here is my haskell code using C for computing it :

{{{
foreign import ccall unsafe ""math.h frexp"" c_frexp::CDouble->(Ptr CInt)->IO ()
foreign import ccall unsafe ""math.h ldexp"" c_ldexp::CDouble->CInt->IO CDouble
ulp::Double->Double
ulp x=unsafePerformIO $ do
  expon<-alloca (\e->do
                    c_frexp (realToFrac x) e
                    peek e)
  (c_ldexp 0.5 $ expon-52) >>= return.realToFrac
}}}",malosh
3,3814,114,"filcab+ghc@…, karel.gardas@…, dankna@…, william.knop.nospam@…, shelarcy@…",Compile to more than one (sub)-architecture,Compiler,6.12.1,_|_,,new,normal,2013-01-21T01:23:43-0800,"GHC, as far as I can tell, can only compile files for one architecture (let's call it the ""host architecture"").

This brings some problems... The biggest of which is that we lose the option of building for 32/64 bits in one of the ""hybrid"" architectures (For example, in x86_64-linux or i386-darwin)

If I build a ghc in a x86_64 linux I will only get the x86_64 code generator and not the i386 generator. This will stop me from building a program which links with a library that only has a 32-bit version.
If I want a GHC which will only compile for the i386, I will have to cross-compile, which is not very pretty.

The same will happen on the Mac OS X side (even though the x86_64-darwin port is still on its way...).


But GHC ""should"" (IMHO) be able to do like GCC and be able to generate code for both architecturess (i386 and x86_64), through the usage of compiler flags (which would also be passed to any gcc sub-process, if need be). At least if it is installed in a x86_64 (and PPC, if PPC64 is supported) system.


Even better would be to do like LLVM's llc which enables a user to generate an assembly file for a target architecture from any other architecture.

Example of an LLVM target list:
{{{
filcab@fry:/stuff/src> llc --version
Low Level Virtual Machine (http://llvm.org/):
  llvm version 2.7svn
  DEBUG build with assertions.
  Built Jan 10 2010 (00:25:59).
  Host: x86_64-unknown-linux-gnu
  Host CPU: core2

  Registered Targets:
    arm     - ARM
    c       - C backend
    cellspu - STI CBEA Cell SPU [experimental]
    cpp     - C++ backend
    mips    - Mips
    msil    - MSIL backend
    ppc64   - PowerPC 64
    sparc   - Sparc
    x86     - 32-bit X86: Pentium-Pro and above
    x86-64  - 64-bit X86: EM64T and AMD64
}}}",filcab
3,1480,113,"Bulat.Ziganshin@…, ezyang@…, v.dijk.bas@…, hackage.haskell.org@…, ddf1991@…",Template Haskell should allow reification of modules,Template Haskell,6.6.1,_|_,,new,normal,2013-03-26T22:57:02-0700,"It should be possible to reify a module from a splice. If the module is thisModule then it would only tell you about things above the current splice.

This comes up quite often; for example:

In http://www.haskell.org/pipermail/haskell-cafe/2007-June/027205.html Brent Yorgey wants to get a list of top-level functions names prop_* in order to build a runQuickCheckProps function.

In http://www.haskell.org/pipermail/haskell-cafe/2007-June/026493.html Neil Mitchell wants to get all the data/newtype declarations in a module in order to declare Typeable and Data instances for them.",igloo
3,2893,113,"id@…, reiner.pope@…, illissius@…, sjoerd@…, shane@…","Implement ""Quantified contexts"" proposal",Compiler,6.10.1,_|_,,new,normal,2013-03-12T06:55:14-0700,"See: http://haskell.org/haskellwiki/Quantified_contexts

Motivating example is collapsing insomeway-identical classes such as Monoid and MonadPlus into a single class (with accompanying functions).",porges
3,5462,111,"wadler@…, jpm@…, hvr@…, dterei, leather@…, illissius@…, erkokl@…",Deriving clause for arbitrary classes,Compiler,7.2.1,7.6.2,,new,normal,2012-09-12T04:12:04-0700,"Currently, you can use a `deriving` clause, or standalone-deriving declaration, only for 
 * a built-in class like `Eq` or `Show`, for which GHC knows how to generate the instance code
 * a newtype, via the ""newtype-deriving"" mechanism.

However, Pedros's new generic-default mechanism means that it makes perfect sense to write this:
{{{
data T a = ...blah..blah... deriving( Generic )

instance C a => C (T a)  -- No 'where' clause
}}}
where C is some random user-defined class.  Usually, an instance decl with no 'where' clause would be pretty useless, but now that we have [http://www.haskell.org/ghc/dist/current/docs/html/users_guide/type-class-extensions.html#class-default-signatures default method signatures], in conjunction with `deriving( Generic )`, the instance ''can'' be useful.

That in turn leads to a desire to say
{{{
data T a = ...blah..blah... deriving( Generic, C )
}}}
which is even more compact.  Is the extra compactness worth it?  Presumably we'd only want to do this for some specified classes C, so we'd need some way to say this at C's declaration site.  Something like:
{{{
class C where
  op :: a -> a
  default op :: blah => a -> a
  op = <code for the default method>

{-# DERIVABLE C #-}   -- This says you can say
                      -- data T = ... deriving( C )
}}}
I'm a bit dubious about whether the payoff justifies the cost, but I'm recording the idea in this ticket.",simonpj
3,6135,111,"dterei, hackage.haskell.org@…, carter.schonwald@…, pho@…, choener@…",Unboxed Booleans,Compiler,7.4.1,7.8.1,,new,normal,2013-06-17T02:41:10-0700,"Right now the only way to compare two integers is with primops that produce boxed bools:

{{{
<#  :: Int# -> Int# -> Bool
==# :: Int# -> Int# -> Bool
}}} 

To consume the resulting {{{Bool}}} we need a case-expression, which introduces branches into the core IR and object code. Case expressions are bad in the presence of heavy inlining because case-of-case performed by the GHC simplifier tends to duplicate code (like in DPH and Repa programs). Mis-predicted branches are bad in object code because they stall the pipeline.


Consider the following expression:
{{{
 case  x <# 0# || x >=# aWidth
    || y <# 0# || y >=# aHeight of 
  True  -> ...
  False -> ...
}}}

This is very common in array programming. Ideally, it should turn into some straight-line code to compute the flag, and then a single branch instruction once we've worked out what alternative to take. However, as the only way to consume the {{{Bool}}}s produced by the comparisons is to introduce more case expressions, we end up with *four* cases in the core IR.

What I want is this:
{{{
data Bool#
(.<#)  :: Int#  -> Int#  -> Bool#
(.==#) :: Int#  -> Int#  -> Bool#
(.||#) :: Bool# -> Bool# -> Bool#

case    x .<# 0# .||# x .>=# aWidth
   .||# y .<# 0# .||# y .>=# aHeight of
 True#  -> ...
 False# -> ...
}}}

Bool# is the type of one bit integers. I can compute with them algebraically and be sure that I'll get at most one branch instruction in the resulting object code.


",benl
2,781,108,"pho@…, vandijk.roel@…, anton.nik@…, dterei, lewurm@…, jims@…","GHCi on x86_64, cannot link to static data in shared libs",Compiler,6.5,7.8.1,,new,high,2013-05-16T01:22:27-0700,"System.Posix.getEnvironment fails on Linux 2.6.16-1.2108_FC4smp
with a segfault. (x86_64)

{{{
[aleator@thoth HopenCV]$ ghci
   ___         ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |      GHC Interactive, version 6.5.20060527, for Haskell 98.
/ /_\\/ __  / /___| |      http://www.haskell.org/ghc/
\____/\/ /_/\____/|_|      Type :? for help.

Loading package base-1.0 ... linking ... done.
Prelude> :m +System.Posix.Env
Prelude System.Posix.Env> getEnv ""USER""
Loading package unix-1.0 ... linking ... done.
Just ""aleator""
Prelude System.Posix.Env> getEnvironment
Segmentation fault
}}}",guest
3,7259,108,"Conor.McBride@…, nfrisby, eir@…, adam.gundry@…, sweirich@…",Eta expansion of products in System FC,Compiler,7.6.1,7.8.1,simonpj,new,normal,2013-06-17T09:56:17-0700,"This ticket is to capture the ideas in these GHC-users threads: [http://www.haskell.org/pipermail/glasgow-haskell-users/2012-August/022790.html PolyKinds Aug 2012] and [http://www.haskell.org/pipermail/glasgow-haskell-users/2012-September/thread.html PolyKinds Sept 2012]

 * We want to add eta-rules to FC.  Sticking to pairs for now, that would amount to adding two new type functions (Fst, Snd), and three new, built-in axioms
{{{
	axPair k1 k2 (a:'(k1,k2)) : a ~ '(Fst a, Snd a)
	axFst k1 k2 (a:k1) (b:k2) : Fst '(a,b) ~ a
	axSnd k1 k2 (a:k1) (b:k2) : Snd '(a,b) ~ a
}}}
  Generalising to arbitrary products looks feasible.

 * Adding these axioms would make FC inconsistent, because 
{{{
	axPair * * (Any '(*,*) ) : Any '(*,*) ~ (Fst .., Snd ..)
}}}
  and that has two different type constructors on each side.  However, I think is readily solved: see below under ""Fixing Any""

 * Even in the absence of Any, it's not 100% obvious that adding the above eta axioms retains consistency of FC.  I believe that Richard is volunteering to check this out.  Right, Richard?

== Type inference ==

I'm a little unclear about the implications for inference.  One route might be this.   Suppose we are trying to solve a constraint
{{{
     [W]  (a:'(k1,ks)) ~ '( t1, t2 )
}}}
where a is an untouchable type variable.  (if it was touchable we'd simply unify it.)  Then we can replace it with a constraint
{{{
    [W]   '(Fst a, Snd a) ~ '( t1, t2)
}}}
Is that it?  Or do we need more?  I'm a bit concerned about constraints like
{{{
    F a ~ e
}}}
where `a:'(k1,k2)`, and we have a type instance like  `F '(a,b) = ...`

Anything else?

I don't really want to eagerly eta-expand every type variable, because (a) we'll bloat the constraints and (b) we might get silly error messages.  For (b) consider the insoluble constraint
{{{
    [W]  a~b
}}}
where `a` and `b` are both skolems of kind `'(k1,k2)`. If we eta-expand both we'll get two insoluble constraints `(Fst a ~ Fst b)` and `(Snd a ~ Snd b)`, and we DEFINITELY don't want to report that as a type error!

Someone pointed out that Agda grapples with this problem and we should talk to them.


== Fixing Any ==

 * I think we can fix the Any problem readily by making Any into a type family, that has no instances.   We certainly allow equalities with a type '''family''' application on the left and a type constructor on the right.

 I have implemented this change already... it seems like a good plan.
	
 * Several people have asked why we need Any at all.  Consider this source program
{{{
         reverse []
}}}
  At what type should we instantiate `reverse` and the empty list `[]`?  Any type will do, but we must choose one; FC doesn't have unbound type variables. So I instantiate it at `(Any *)`:
{{{
         reverse (Any *) ([] (Any *))
}}}
  Why is Any poly-kinded?  Because the above ambiguity situation sometimes arises at other kinds.

 * I'm betting that making Any into a family will mess up Richard's (entirely separate) use of `(Any k)` as a proxy for a kind argument `k`; because now `(Any k1 ~ Any k2)` does not entail `(k1~k2)`. See also the module `GHC.TypeLits` in `base`.  

 We can't solve this by making `Any` to be an ''injective'' type family, because the use in `TypeLits` uses it in a type-class instance, and you can't match on type families!
",simonpj
3,1800,107,"alfonso.acosta@…, Deewiant, reiner.pope@…, eir@…, hackage.haskell.org@…",Template Haskell support for running functions defined in the same  module,Template Haskell,7.7,_|_,,new,normal,2013-03-25T03:54:32-0700,"Currently TH has the following restriction:

  You can only run a function at compile time if it is imported from another module. That is, you can't define a function in a module, and call it from within a splice in the same module.

This is a pain. It should be fixed.

See http://www.haskell.org/pipermail/template-haskell/2007-October/000619.html, for example.
",simonpj
3,2189,104,"camio, igloo, Deewiant, ryani, sof, ddiaz, Artyom.Kazak@…, malaquias@…, dagitj@…",hSetBuffering stdin NoBuffering doesn't work on Windows,libraries/base,6.8.2,7.6.2,,new,normal,2013-03-02T21:05:32-0800,"The following program repeats inputted characters until the escape key is pressed.


{{{
import IO
import Monad
import Char

main :: IO ()
main = do hSetBuffering stdin NoBuffering
          inputLoop
          
inputLoop :: IO ()
inputLoop = do i <- getContents
               mapM_ putChar $ takeWhile ((/= 27) . ord) i
}}}


Because of the ""hSetBuffering stdin NoBuffering"" line it should not be necessary to press the enter key between keystrokes. This program works correctly in WinHugs (sep 2006 version). However, GHC 6.8.2 does not repeat the characters until the enter key is pressed. The problem was reproduced with all GHC executables (ghci, ghc, runghc, runhaskell), using both cmd.exe and command.com on Windows XP Professional.",FalconNL
2,5642,103,"v.dijk.bas@…, dimitris@…, hackage.haskell.org@…, carter.schonwald@…",Deriving Generic of a big type takes a long time and lots of space,Compiler,7.3,7.6.2,dimitris,new,high,2013-04-05T22:14:39-0700,"If I load the following module into `ghci` my system will run out of memory after about 15 minutes: 

{{{
{-# LANGUAGE DeriveGeneric #-}

import GHC.Generics

data BigSum = 
    C0   |  C1  | C2   | C3   | C4   | C5   | C6   | C7   | C8   | C9 
  | C10  | C11  | C12  | C13  | C14  | C15  | C16  | C17  | C18  | C19 
  | C20  | C21  | C22  | C23  | C24  | C25  | C26  | C27  | C28  | C29
  | C30  | C31  | C32  | C33  | C34  | C35  | C36  | C37  | C38  | C39
  | C40  | C41  | C42  | C43  | C44  | C45  | C46  | C47  | C48  | C49
  | C50  | C51  | C52  | C53  | C54  | C55  | C56  | C57  | C58  | C59
  | C60  | C61  | C62  | C63  | C64  | C65  | C66  | C67  | C68  | C69
  | C70  | C71  | C72  | C73  | C74  | C75  | C76  | C77  | C78  | C79
  | C80  | C81  | C82  | C83  | C84  | C85  | C86  | C87  | C88  | C89
  | C90  | C91  | C92  | C93  | C94  | C95  | C96  | C97  | C98  | C99
  | C100 | C101 | C102 | C103 | C104 | C105 | C106 | C107 | C108 | C109
  | C110 | C111 | C112 | C113 | C114 | C115 | C116 | C117 | C118 | C119
  | C120 | C121 | C122 | C123 | C124 | C125 | C126 | C127 | C128 | C129
  | C130 | C131 | C132 | C133 | C134 | C135 | C136 | C137 | C138 | C139
  | C140 | C141 | C142 | C143 | C144 | C145 | C146 | C147 | C148 | C149
  | C150 | C151 | C152 | C153 | C154 | C155 | C156 | C157 | C158 | C159
  | C160 | C161 | C162 | C163 | C164 | C165 | C166 | C167 | C168 | C169
  | C170 | C171 | C172 | C173 | C174 | C175 | C176 | C177 | C178 | C179
  | C180 | C181 | C182 | C183 | C184 | C185 | C186 | C187 | C188 | C189
  | C190 | C191 | C192 | C193 | C194 | C195 | C196 | C197 | C198 | C199
  | C200 | C201 | C202 | C203 | C204 | C205 | C206 | C207 | C208 | C209
  | C210 | C211 | C212 | C213 | C214 | C215 | C216 | C217 | C218 | C219
  | C220 | C221 | C222 | C223 | C224 | C225 | C226 | C227 | C228 | C229
  | C230 | C231 | C232 | C233 | C234 | C235 | C236 | C237 | C238 | C239
  | C240 | C241 | C242 | C243 | C244 | C245 | C246 | C247 | C248 | C249
  | C250 | C251 | C252 | C253 | C254 | C255 | C256 | C257 | C258 | C259
  | C260 | C261 | C262 | C263 | C264 | C265 | C266 | C267 | C268 | C269
  | C270 | C271 | C272 | C273 | C274 | C275 | C276 | C277 | C278 | C279
  | C280 | C281 | C282 | C283 | C284 | C285 | C286 | C287 | C288 | C289
  | C290 | C291 | C292 | C293 | C294 | C295 | C296 | C297 | C298 | C299
   deriving Generic
}}}

Big products have the same problem:

{{{
data BigProduct = C 
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    () () () () () () () () () ()
    deriving Generic
}}}
",basvandijk
3,7353,100,"idhameed@…, bos@…, shelarcy@…, dagitj@…, leon.p.smith@…",Make system IO interruptible on Windows,libraries/base,7.6.1,7.8.1,,new,normal,2013-06-05T16:02:20-0700,"Currently, IO operations (connect, read, etc.) cannot be interrupted on Windows.  Additionally, threadWaitRead and threadWaitWrite do not work on Windows (IIRC, they can't tell if the given file descriptor is a socket or not, so they assume it's not).

The reason is that GHC does not have an IO manager for Windows like it does for *nix.  For Windows with -threaded, the network package uses blocking FFI calls, which cannot be interrupted by asynchronous exceptions.  Thus, System.Timeout and killThread can't be used to time out and interrupt network IO.

I'm working on a program that needs to run on a Windows XP machine for long periods of time, interacting with a couple intermittent network services.  This issue is making things very difficult for me, so I want to get it fixed.  I do not need to support thousands of concurrent connections efficiently; I just need my program to run reliably.

What needs to happen for IO to be interruptible on Windows with -threaded ?  I'm willing to put in the work, but there's a lot I'd have to learn about windows IO and GHC IO handling.  One question to get started: are threadWaitRead/threadWaitWrite even possible to implement on Windows, or might Windows assign overlapping HANDLE numbers to sockets and regular files?

This issue spans both GHC and the network package, but I'd like to collect information about it in one place.  Related issues:

 * http://trac.haskell.org/network/ticket/2

 * https://github.com/haskell/network/issues/36

 * http://hackage.haskell.org/trac/ghc/ticket/3937

 * http://hackage.haskell.org/trac/ghc/ticket/5797",joeyadams
4,5550,100,"rl, v.dijk.bas@…, hackage.haskell.org@…, tkn.akio@…, amos.robinson@…",GHC infinite loop when compiling vector,Compiler,7.2.1,7.6.2,,merge,low,2013-04-03T00:43:20-0700,"Bas reports: When benchmarking my new [https://github.com/basvandijk/vector-bytestring vector-bytestring] package I discovered that building the following program causes GHC to go into, what seems to be, an infinite loop:
{{{
import Data.Vector (Vector)
import qualified Data.Vector.Generic as VG

main = print $ VG.foldl f z (VG.fromList [] :: Vector Int)

f = flip (:)
z = []
}}}
I build it with:
{{{
$ ghc --make vectorGHCloop.hs -O2
}}}
It compiles fine without the -O2 or if you specify `-fno-enable-rewrite-rules`. So it's probably a loop in a rule somewhere.

Note that the program also builds fine when I change the 'f' and 'z' to:
{{{
f = (+)
z = 0
}}}

I use vector-0.9 and ghc-7.2.1.

",simonpj
3,4900,99,"michael@…, patrick@…, sol@…, ryant5000@…, idhameed@…",DEPENDS pragma,Compiler,,7.6.2,,new,normal,2013-01-07T20:19:11-0800,"Since a seemingly-growing amount of Haskell code is using Template Haskell to read and include data from external sources, it would be nice if GHC recognized a pragma for specifying additional build dependencies for a source file.  Such a pragma could be required to appear before the module headers, and look like:

    {-# DEPENDS ""file.dat"" #-}

ghc --make would add it to other dependencies when deciding what modules to rebuild.  The file would NOT be one that's generated by some other build step, but rather play the role of an additional source file, so it would have no effect on the order of compiling modules.  My gut says to just make it an error if the file does not exist.

One example of a place this is called for is Michael Snoyman's Yesod and external hamlet files (e.g., hamletFile in the hamlet package).  These are plastered all over the place with warnings that if you use them, GHC will no longer automatically rebuild everything it needs to.",cdsmith
3,7606,97,"jwlato@…, wren@…, hackage.haskell.org@…, ikke+ghc@…",Stride scheduling for Haskell threads with priorities,Runtime System,7.7,7.8.1,ezyang,new,normal,2013-04-23T08:24:53-0700,"Currently, GHC uses a round-robin scheduler for Haskell threads, with some heuristics for when threads should be bumped to the front of the queue.  This patch set replaces this scheduler with 'stride scheduling', as described by Waldspurger and Weihl '95, which is an efficient, deterministic method for scheduling processes with differing priorities. Priorities are assigned by giving 'tickets' to threads; a thread with twice as many tickets as another will run twice as often. I’d like to replace the round-robin scheduler completely with this scheduler.

Here are nofib benchmarks comparing the old scheduler to the new:

{{{
--------------------------------------------------------------------------------
        Program           Size    Allocs   Runtime   Elapsed  TotalMem
--------------------------------------------------------------------------------
            Min          -0.0%    -52.2%    -18.8%    -18.6%    -83.1%
            Max          +1.0%     +4.2%     +4.9%     +5.1%     +7.7%
 Geometric Mean          +0.1%     -2.8%     -0.9%     -0.9%     -2.9%
}}}

Here are some technical details:

 * Without any changes to ticket values, scheduling behavior should be functionally identical to round-robin. (By default, new threads, including the IO thread, get allocated the max nubmer of tickets possible.) This is not quite identical, since our heap does not have FIFO property (see below.)

 * The current patch-set uses a very simple (e.g. undergrad level) resizable-array backed heap to implement the priority queue; we can play some tricks to reduce the memory footprint of the priority queue (e.g. using the container_of macro to eliminate the extra keys store); and a more fancy data structure would make it easier for us to surgically remove entries or reweight them, but I wanted to keep overhead low. If anyone has a pet implementation of priority queues in C feel free to swap it in. Right now, this only affects the uses of promoteInRunQueue() in Messages.c; I still need to check if #3838 has regressed.

 * We get three new primops: `setTickets#`, `getTickets#` and `modifyTickets#`. We don't support creating threads with specific numbers of tickets (mostly because that would have added an annoyingly large set of extra primops); instead, you're expected to spawn a thread which gets max-ticket allocation, and then weight it down.

 * `_link` is no longer used for linking TSOs in the run queue. I have tried my best to stamp out any code which operated on this assumption, but I may have missed some.

 * Modifying a TSO's tickets takes out the scheduler lock; the hope is that this operation is quick and rare enough that a global lock here is not too bad.

 * We are unfortunately stuck with some magic constants w.r.t. ticket values: 1 << 20 is the maximum number of tickets our implementation is hard-coded to support.

 * Sleeping and blocked tasks do not get any 'bonus' for being blocked.

 * In an ideal world, when a thread hits a black hole, it should temporarily give its tickets to the thread evaluating the black hole, so it will unblock more quickly.  Unfortunately, implementing this is pretty complicated (the blackhole evaluating thread could die; or it could get stuck on a blackhole itself and need to gift its tickets; it shouldn't be able to give away the tickets it was gifted.) So this implementation leaves that out. Similar semantics for MVars are probably possible, but will require userland assistance too.

I haven't prepared a patch to base yet with a user-level API, but here is a proposed draft:

{{{
type Tickets = Int

-- | Maximum number of tickets we support a thread having. (Currently 2 >> 20)
-- Note that this doesn't bound the *global* maximum tickets.
maxTickets :: Tickets

-- | Changes the number of tickets allocated to a thread.  The ticket count must
-- not be less than or equal to zero, or greater than maxTickets. (Corresponds
-- to setTickets# primop)
setTickets :: ThreadId -> Tickets -> IO ()

-- | Returns the number of tickets currently allocated to a thread.  (Corresponds to
-- getTickets# primop)
getTickets :: ThreadId -> IO Tickets

-- | Atomically performs a linear transformation on the number of tickets a thread;
-- e.g. scaling the number of tickets by a rational number, adding another fixed
-- set of tickets, and then returning the number of 'leftover' tickets from the operation; e.g.
-- if the net amount of tickets is reduced, then the returned result is positive;
-- if the net amount of tickets is increased, the returned result is negative.
-- In the absence of concurrent threads, the following property holds forall
-- t, m and x:
--
--      do r <- getTickets t
--         d <- scaleTickets t m x
--         r' <- getTickets t
--         return (r == r' + d)
--
-- If the scaling would reduce the number of tickets below zero or increase the
-- number of tickets beyond maxTickets, this function will instead fail with
-- an exception.  This function will be subject to some rounding error; powers of two
-- are, however, likely to be exact.  (Corresponds to modifyTickets# primop; note
-- that the sentinel value for failure is maxTickets + 1, since it is impossible for
-- a thread's ticket value to change by that much.)
modifyTickets :: ThreadId -> Ratio Int -> Tickets -> IO Tickets

-- | Forks a new thread, transferring some percentage of tickets from the current
-- thread to it (so the net number of tickets stays constant.)  Fails if the rational
-- is greater than 1 or less than or equal to zero, or if there are not enough tickets
-- in the current thread.
forkIOWith :: IO a -> Ratio Int -> IO ThreadId

}}}",ezyang
3,960,97,"claus.reinke@…, ndmitchell@…, id@…, pho@…",Lexical call site string,Compiler,6.6,_|_,,new,normal,2011-04-02T09:11:41-0700,"A function that returns the lexical call site of the current function when an exception occurs.

I'm thinking primarily of ""head []"", but the same principle would apply to other functions.  A dynamic traceback is not necessarily possible in a lazy language, but when ""head"" gets called on an empty list there must be somewhere in the program that actually said ""head"", even if it was not evaluated at the time or included in a closure or something.  That way when I get a ""head: empty list"" I don't need to grep my program for ""head"" calls: I know where head was called from and can start looking there.  

Examples:

* If I just have a function ""foo = head"" then it will report that the caller was ""foo"".  

* If I have a function ""bar x y = ..."" and subsequntly say ""baz x = bar (x * 2)"" then an exception in ""bar"" will report the caller as ""baz"".

I know there is a -x profiler option to get a sort of dynamic traceback, but I find it frequently just tells me the error is in ""CAF.List"", which isn't very informative.

I'm guessing at a difficulty of 1 week as I don't know the GHC internals.  I'm guessing that the call site is going to have to be a hidden parameter passed in to each function call, or alternatively hard-coded when a function is in-lined.",paul@…
2,3658,95,"morrow@…, howard_b_golden@…, pho@…, dterei, bos@…",Dynamically link GHCi (and use system linker) on platforms that support it,GHCi,6.10.4,7.8.1,igloo,new,high,2013-04-24T05:23:30-0700,"In 6.14.1 we should switch to shipping a dynamically linked GHCi binary, on those platforms for which dynamic linking is supported (currently Linux; MacOS X and Windows support is in progress).

== Advantages ==

 * The GHCi binary is smaller
 * some packages don't need to be loaded on startup: lower memory use
 * GHCi startup might be quicker (or it might not)
 * some hacks due to having two copies of the base package are not
   necessary (see `rts/Globals.c`)
 * We might save some space in the distributions.
 * It takes us a step closer to not needing the RTS linker at all
 * It takes us a step closer to using dynamic linking by default, which
   is where we want to go ultimately

== Potential Issues ==

 * Do we run into any problems with GHCi and the user program sharing the same
   stdin/stdout/stderr handles?  Do we need to virtualise these explicitly in the
   GHCi front end?

 * We cannot revert CAFs in packages that are shared by GHC and the user program.
   There are some old non-working hacks related to reverting CAFs when GHCi is
   dynamically linked (see `KeepCAFsForGHCi`) that
   need to be cleaned out.  CAFs can only be reverted in code loaded by the RTS
   linker.  We need to think about whether this is a necessary feature or not:
   we have never supported CAF reverting for interpreted code anyway.  One
   reason to have it was so that you can recover after saying `getContents` at
   the GHCi prompt, but we can provide other ways to work around that.

 * There will be installation/binary-dist issues to resolve; currently we don't
   install any dynamically-linked binaries.

== Open questions ==

 * Whether we continue to use the same binary for GHC and GHCi is an open question:
   it would be possible to provide a separate statically-linked GHC binary if
   performance of the dynamically-linked version was an issue.

 * We might as well dynamically-link Haddock, and the other tools that come
   with GHC too.

",simonmar
3,1216,94,"Bulat.Ziganshin@…, claus.reinke@…, daniel.is.fischer@…, sveina@…",Missed opportunity for let-no-esape,Compiler,6.6,7.6.2,simonpj,new,normal,2012-09-12T04:11:56-0700,"readArray/writeArray call GHC.Arr.index, which seems inexplicably slow
for 2d arrays. inexplicably, because simply copying the default implementation
of index from GHC.Arr into the local module can speed things up considerably.

originally raised in this thread:
http://www.haskell.org/pipermail/haskell-cafe/2007-March/023394.html

shortened example or matrix/vector-multiplication attached. comment out
the first line of myindex to use the local copy. this results in a speedup
from 20s to 13s (time ./Index 100000) on my system, not to mention the
difference in space usage (a factor of 1000 in allocation, according to
+RTS -sstderr..).",claus
3,7495,93,"giorgidze@…, info@…, jeroen.weijers@…, eir@…",Rebindable list syntax?,Compiler,7.6.1,7.8.1,,new,normal,2013-04-12T14:08:39-0700,"First, sorry if I've missed an earlier request for this in trac; a few searches did not turn up anything relevant.

I've recently taken to doing a lot of work with heterogenous lists (thanks to the DataKinds work) and find the forced-cons-and-nil style of writing lists (e.g. ""a:+b:+c:+HN"") to be sort of unpleasant.

Would it be possible to allow rebinding list-literal syntax?  Off the top of my head I think something like the following might be workable, if only I could stop [] and (:) from being in scope, even with -XNoImplicitPrelude.  (Example requires -XDataKinds -XFlexibleInstances -XGADTs -XMultiParamTypeClasses -XTypeOperators)

{{{
class HasNil a where
  ([])  :: a
  isNil :: a -> Bool

class HasCons e l l' | e l -> l', l' -> e l where
  (:)    :: e -> l -> l'
  uncons :: l' -> Maybe (e,l)

-- For homogeneous lists...
instance HasNil [a] where
  ([])  = ([])
  isNil = null

instance (a ~ a1, a ~ a2) => HasCons a [a1] [a2] where
  (:)           = (:)
  uncons []     = Nothing
  uncons (x:xs) = Just (x,xs)

-- For HLists...
data HList as where
  HN   :: HList '[]
  (:+) :: a -> HList as -> HList (a ': as)

instance HasNil (HList '[]) where
  ([])  = HN
  isNil = const True

instance (a ~ a1, as ~ as1) => HasCons a (HList as) (HList (a1 ': as1)) where
  (:)              = (:+)
  uncons (a :+ as) = Just (a,as)
}}}",nwf
3,7870,92,"eir@…, byorgey@…, ozgurakgun@…, rendel@…","Compilatio​n errors break the complexity encapsulat​ion on DSLs, impairs success in industry",Compiler (Type checker),7.7,,,new,normal,2013-05-05T11:02:16-0700,"From the paper ""Scripting the Type Inference Process"" -Bastiaan Heeren Jurriaan Hage S. Doaitse Swierstra:


... Combinator languages are a means of defining domain specific languages embedded within an existing programming language, using the abstraction facilities present in the latter. However, since the domain specific extensions are mapped to constructs present in the underlying language, all type errors are reported in terms of the host language, and not in terms of concepts from the combinator library. In addition, the developer of a combinator library may be aware of various mistakes which users of the library can make, something which he can explain in the documentation for the library, but which he cannot make part of the library itself.

...As a result, the beginning programmer is likely to be discouraged from pro-gramming in a functional language, and may see the rejection of programs as a nuisance instead of a blessing. The experienced user might not look at the messages at all.

Definitively this is probably the biggest barrier for the acceptance of Haskell on Industry. We need to start with something not as sophisticated as  the Helium paper ""Scripting the Type Inference Process"", but maybe a partial implementation of the techniques mentioned, so that the development can be enhanced in the future. 

Maybe some kind of  library that permits postprocessing of GHC errors and/or the identification of points in the current type checker where some kind of rules can be defined by the programmer can be the first step. ",agocorona
3,7374,92,"kazu@…, carter.schonwald@…, duncan@…, pho@…",rule not firing,Compiler,7.6.1,7.8.1,,new,normal,2012-11-19T17:37:00-0800,"In the code below, the rule appears not to fire.

Based on the bytestring rules, reported as broken here:
http://www.haskell.org/pipermail/glasgow-haskell-users/2012-August/022775.html

{{{
ghc -O --make h.hs -ddump-simpl -fforce-recomp -Wall
}}}
{{{
module Q (f) where

{-# NOINLINE f #-}
f :: Bool -> String
f c = g ((==) c)

{-# NOINLINE g #-}
g :: (Bool -> Bool) -> String
g _ = ""g""

h :: Bool -> String
h _ = ""h""

{-# RULES ""MyRule"" forall x . g ((==) x) = h x #-}
}}}
{{{
==================== Tidy Core ====================
Result size of Tidy Core = {terms: 25, types: 21, coercions: 0}

lvl_rkK :: GHC.Types.Char
[GblId, Caf=NoCafRefs, Str=DmdType m]
lvl_rkK = GHC.Types.C# 'h'

lvl1_rkL :: [GHC.Types.Char]
[GblId, Caf=NoCafRefs, Str=DmdType]
lvl1_rkL =
  GHC.Types.:
    @ GHC.Types.Char lvl_rkK (GHC.Types.[] @ GHC.Types.Char)

h_reA :: GHC.Types.Bool -> GHC.Base.String
[GblId, Arity=1, Caf=NoCafRefs, Str=DmdType A]
h_reA = \ _ -> lvl1_rkL

lvl2_rkM :: GHC.Types.Char
[GblId, Caf=NoCafRefs, Str=DmdType m]
lvl2_rkM = GHC.Types.C# 'g'

lvl3_rkN :: [GHC.Types.Char]
[GblId, Caf=NoCafRefs, Str=DmdType]
lvl3_rkN =
  GHC.Types.:
    @ GHC.Types.Char lvl2_rkM (GHC.Types.[] @ GHC.Types.Char)

g_rez :: (GHC.Types.Bool -> GHC.Types.Bool) -> GHC.Base.String
[GblId, Arity=1, Caf=NoCafRefs, Str=DmdType A]
g_rez = \ _ -> lvl3_rkN

Q.f [InlPrag=NOINLINE] :: GHC.Types.Bool -> GHC.Base.String
[GblId, Arity=1, Caf=NoCafRefs, Str=DmdType A]
Q.f =
  \ (c_aeC :: GHC.Types.Bool) ->
    g_rez (GHC.Classes.$fEqBool_$c== c_aeC)
}}}
",igloo
4,3990,92,"hackage.haskell.org@…, reiner.pope@…, tomberek@…, tkn.akio@…",UNPACK doesn't unbox data families,Compiler,7.0.3,7.6.2,,new,low,2013-02-06T02:26:06-0800,"Here is an example:

{{{
data family Complex a
data instance Complex Double = CD {-# UNPACK #-} !Double
                                  {-# UNPACK #-} !Double

data T = T {-# UNPACK #-} !(Complex Double)
}}}

We would like T to just store two Double# but that doesn't happen. Contrast this with

{{{
data Complex_Double = CD {-# UNPACK #-} !Double
                         {-# UNPACK #-} !Double

data T = T {-# UNPACK #-} !Complex_Double
}}}
",rl
3,3654,90,"mnislaih@…, morrow@…, hgolden, pho@…, anton.nik@…",Mach-O GHCi linker lacks support for a range of relocation entries,Runtime System,6.13,7.6.2,,new,normal,2012-09-12T04:11:58-0700,"The Mach-O code of the GHCi linker `rts/Linker.c` lacks support for a range of relocation entries.  It used to silently ignore many of them.  The following patch makes it barf() when it encounters an unsupported entry:
{{{
Wed Nov 11 13:07:12 EST 2009  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Barf on unhandled Mach-O relocations in the ghci linker
  
  - It might be worthwhile to MERGE this to 6.12, BUT somebody should validate
    it on PPC/Mac OS X first.
}}}
Moreover, at least one entry type —i.e., `GENERIC_RELOC_LOCAL_SECTDIFF`— is not correctly implemented.

This is an unsatisfactory situation as the transition from Mac OS X 10.5 (Leopard) to 10.6 (Snow Leopard) showed.  In that case, changes in `ld` suddenly created a so far unsupported entry type.  This was before the above patch; so, the ignored entry led to an incorrectly relocated image, which crashed GHCi with a SIGBUS.

Instead of trying to improve the dynamic linker, IMHO, GHC should use dynamic libraries with `dlopen()` and leave the implementation of dynamic linking to the OS vendor.  This has a number of advantages:
 * The RTS gets smaller & simpler, and we eliminate a whole category of potentially tricky bugs.
 * Dynamically loaded code can use dtrace probes (and other features requiring linker trickery).
 * Packages that GHC links to, don't need to be in memory twice (once statically and once dynamically linked).
 * Potential performance advantage due to optimisations in the OS' dynamic linker.

The main obstacle with using dynamic libraries and `dlopen()` appears to be the required on-the-fly conversion of GHC-generated object files into dynamic libraries.  Otherwise, SimonM says that it is already possible to compile GHC itself dynamically-linked at the moment that the linker will then use `dlopen()` for loading packages.

More details are in the following thread on `cvs-ghc@haskell.org`:
  [http://www.haskell.org/pipermail/cvs-ghc/2009-November/050941.html]
  [http://www.haskell.org/pipermail/cvs-ghc/2009-October/050893.html]

",chak
2,4012,87,"mail@…, the.dead.shall.rise@…, id@…",Compilation results are not deterministic,Compiler,6.12.2,7.6.2,,new,high,2013-02-14T12:51:19-0800,"There are some issues with non-determinism in the output of GHC, which means that compilations are not repeatable.  This affects some users (e.g. Debian packagers) who need to be able to get repeatable hashes for the packages of a GHC build.

The cases we know about that lead to non-deterministic results are:

 * The `spec_ids` (specialised Ids) attached to an Id have a non-deterministic ordering
 * CSE can give different results depending on the order in which the bindings are considered, and since the ordering is non-deterministic, the result of CSE is also non-deterministic.  e.g. in `x = z; y = z; z = 3`, where `y` and `x` are exported, we can end up with either `x = y; y = 3` or `y = x; x = 3`.
 * There seems to be something unpredictable about the order of arguments to SpecConstr-generated specialisations, see [http://www.haskell.org/pipermail/glasgow-haskell-users/2011-April/020287.html]
 * The wrappers generated by the `CApiFFI` extension have non-deterministic names. (see comment:15 below).

'''Old ticket description follows'''

Short story: if you use ghc-6.12.1.20100318 (or similar, probably
ghc-6.12.1 release will produce the same results) to bootstrap
ghc-6.12, and then use that ghc-6.12 to bootstrap another ghc-6.12,
those two instances of ghc-6.12 will have different ABI hashes and
interfaces in the ghc package. If you use ghc-6.10 for the
bootstrapping, you'll even get differences in the ghc, base and
Cabal packages.

Long story: see logfiles and descriptions at http://darcs.volkswurst.de/boot-tests/ (note that the logfiles are quite large, I really don't want to attach 150 MB of logs to this ticket).",kili
3,989,87,"ndmitchell@…, fryguybob@…, dterei, dagitj@…, idhameed@…","Windows ""native"" port",Compiler,,_|_,,new,normal,2013-01-20T17:06:21-0800,"Create a Windows ""native"" port of GHC, i.e. one that uses the Microsoft toolchain instead of GCC and the GNU binutils.  The main tasks are:

 * Convert the pretty printer in the i386 NCG to generate MS/Intel syntax
   instead of AT&T syntax.  We can then generate assembly code that MASM can
   grok.

 * Make the RTS compile with Microsoft's CL compiler.  (this has been done in
   the past, so shouldn't be too much work).

 * Drop any dependencies on mingw32 functionality in the libraries.

 * Make appropriate modifications to the driver, build system etc.  We'd still
   need Cygwin/MSYS for build tools (dropping dependency on GNU make is another task
   entirely...)",simonmar
3,7436,86,"patrick@…, twanvl, dreixel, hackage.haskell.org@…, jwlato@…",Derived Foldable and Traversable instances become extremely inefficient due to eta-expansion,Compiler,7.6.1,7.6.3,,merge,normal,2013-04-16T08:55:15-0700,"The following program:

{{{
{-# LANGUAGE DeriveFunctor, DeriveFoldable #-}
import Prelude hiding (foldr)
import Data.Foldable

data List a = Nil | Cons a (List a)
    deriving (Functor, Foldable)

mkList :: Int -> List Int
mkList 0 = Nil
mkList n = Cons n (mkList (n-1))

main :: IO ()
main = print $ foldr (\x y -> y) ""end"" (mkList n)
  where n = 100000
}}}

Takes `n^2` time to run with GHC 7.6.1 -O2.

The generated `Foldable` code looks something like this:

{{{
instance Foldable List where
    foldr f z Nil = z
    foldr f z (Cons x xs) = f x (foldr (\a b -> f a b) z xs)
}}}

Eta-reducing the function, i.e.

{{{
instance Foldable List where
    foldr f z Nil = z
    foldr f z (Cons x xs) = f x (foldr f z xs)
}}}

Makes the program linear in `n` (in this case, runtime goes from 8.160s to 0.004s).

The `Traversable` instance also has the same issue.

There seem to be three different issues:

 * Derived `Foldable` and `Traversable` instances are nearly unusable for large structures.

 * An eta-expanded definition like `foldr` becomes asymptotically worse for some reason. Maybe this is expected behavior for this function, since `f` gets eta-expanded at each iteration?

 * `Foldable` instances are generated with `foldr` instead of `foldMap`.

This isn't directly related, since the code would have the same problem either
way, but since I'm already writing about it... `foldMap` can allow
asymptotically better operations on a structure than `foldr` (for example,
finding the rightmost leaf of a binary tree using `Data.Monoid.Last`), so it
should probably be generated instead. A `foldMap` definition should look like a
simpler version of `traverse`, which is already derivable. Maybe this should be
a separate ticket.",shachaf
3,4372,85,"kfisher@…, gershomb@…, michael@…, pho@…",Extending quasiquotation support,Template Haskell,6.12.3,7.6.2,,new,normal,2012-09-12T04:12:00-0700,"Gershom Bazerman (gershomb@gmail.com) writes: Attached is an experimental patch (not read for prime-time) that extends quasiquotation syntax. At the moment, quasiquoters can only be single identifiers of type `QuasiQuoter` (and of course declared outside the current module). This patch allows an entire expression of type `QuasiQuoter` in the quoter position. The staging restriction is extended to all free variables in the quasiquoter expression.

So if `qq1 :: Int -> QuasiQuoter`, one can now write `[$qq1 12 | ... |]`

This syntax would be quite useful for my own project (jmacro), and from discussions at ICFP, to others who also are beginning to take serious advantage of quasiquotation.

Here's one use case. Suppose jmt is a `QuasiQuoter` which returns both a parsed Javascript expression and its ""module signature"" (or ""typing environment"" if you prefer). Then, one can pass that typing environment directly into another quasiquoter in a different module, so that further code can be typechecked at compile-time with functions defined in the first quasiquote available to the Javascript typechecker. This style of programming is currently possible, but it requires defining additional new modules which contain `QuasiQuoters` parameterized with each successive typing environment.

There are a number of tricky choices made in this patch, not all of which are perhaps correct.

First, currently, the quoter and quotation are lexed and parsed as a single token. To avoid reinvoking the lexer and/or parser, now '[$' is lexed as one token, and a flag is set in the lexer state which lexes the `|...|]` (i.e. the quotation) as a single quotation on encountering the first vbar. This means that guards can't be used inside a quasiquoter expression -- i.e. `[$let x | True = 1 in qq1 x|..|]` would fail to parse. This also means that while now in ghc 7, one can write `[qq|..]`, to parse a full expression rather than identifier, we need the dollar sign as well.

The former problem (stealing guards within quasiquoter expressions) can be fixed by a syntax change which moves from a single vbar to a new symbol (perhaps `$|` or `||` ?) to signal the transition between the quoter expression and the quote itself. I tend to feel that the loss of guards within quasiquoter expressions is not too painful, however. Adding a new symbol between quoter and quotee also would simplify the necessary changes to the lexer, removing the need to set a special flag in the lexer state.

The second problem (need to reintroduce a dollar) is somewhat irritating, but not terribly so. One could either introduce the dollar in all cases, which allows simplifying the lexer and parser, or keep the dollarless syntax as well for single identifiers, which adds both complexity and duplicate syntax, but keeps the default case especially lightweight.

The patch as it stands introduces ""extended quasiquotations"" as an orthogonal change that doesn't affect the existing quasiquotation machinery, and, at the moment, only allows for quasiquotations of expressions (i.e., not patterns, etc.).

If there is sentiment that this is useful and could be accepted, modulo whatever requested tweaks, I'd be happy to do whatever work is necessary -- implementing changes, adding documentation, pushing the changes through to quasiquoters in other positions, etc.
",simonpj
3,3984,85,"vogt.adam@…, johan.tibell@…, haskell.vivian.mcphail@…, dterei",Handle multiline input in GHCi history,GHCi,6.12.1,7.6.2,,new,normal,2012-09-12T04:11:59-0700,"GHCi accepts multiline input in the form of:

{{{
Prelude> :{
Prelude|   let f = do
Prelude|         print ""Hello""
Prelude|         print ""World""
Prelude|   :}
}}}

OR of the form:

{{{
Prelude> :set +m
Prelude|   let f = do
Prelude|             print ""Hello""
Prelude|             print ""World""
Prelude|   
Prelude>
}}}

However, recalling mulitline input from history (with the <Up> key or <C-p>) recalls it as its individual lines, not the whole input. Ideally multiline should be one history entry and allow proper editing of the recalled text.",aavogt
3,7542,85,"ekmett@…, jwlato@…, hackage.haskell.org@…, pho@…",GHC doesn't optimize (strict) composition with id,Compiler,7.6.1,7.8.1,simonpj,new,normal,2013-04-12T15:08:37-0700,"Newtype constructors and selectors have no runtime overhead, but some uses of them do. For example, given `newtype Identity a = Identity { runIdentity :: a }`, `Identity` turns into `id`, but `Identity . f` turns into `id . f`, which is distinct from `f`, because it gets eta-expanded to `\x -> f x`.

It would be nice to be able to compose a newtype constructor with a function without any overhead. The obvious thing to try is strict composition:

{{{
(#) :: (b -> c) -> (a -> b) -> a -> c
(#) f g = f `seq` g `seq` \x -> f (g x)
}}}

In theory this should get rid of the eta-expansion. In practice, the generated Core looks like this:

{{{
foo :: (a -> b) -> [a] -> [b]
foo f = map (id # f)
-- becomes
foo = \f e -> map (case f of g { __DEFAULT -> \x -> g x }) e
}}}

Different variations of `(#)`, and turning `-fpedantic-bottoms` on, don't seem to affect this. A simpler version, `foo f = map (f `seq` \x -> f x)`, generates the same sort of Core.

In one library we resorted to defining a bunch of functions of the form `identityDot :: (a -> b) -> a -> Identity b; identityDot = unsafeCoerce`. It would be better to be able to rely on GHC to do the optimization directly, if we use strict composition anyway.",shachaf
3,5144,85,"lennart.augustsson@…, illissius@…, bgamari@…, cgibbard@…",Pattern synonyms,Compiler,,_|_,,new,normal,2012-10-12T07:59:23-0700,"Lennart would like pattern synonyms.  Something like
{{{
pattern con var1 … varN = pat
}}}
where ‘pattern` is a new keyword.  
 * Perhaps there should be a way to give a type as well, so the `con` could be `(con :: type)`.
 * The `rhs` is type checked as a usual pattern, i.e., in the global environment.  
 * The `pat` should bind exactly `var1` .. `varN`.
 * Recursive pattern synonyms are not allowed.

With `con` in scope it can be used like any other constructor in a pattern, and the semantics is simply by expansion.

It would have been very nice if `con` could be used in expressions as well, but I don’t see how that could work with view patterns.
Perhaps view patterns could be extended to make them bidirectional.

My rationale for wanting pattern synonyms is that I sometimes have pattern matching with a lot of complex repetition in them.
I’ve even resorted to using CPP in the past, and that just shows that Haskell is lacking some abstraction mechanism.

If pattern synonyms could be made to work in the presence of view pattern it would offer a mechanism for normal pattern matching on abstract types, since the abstract type could export some pattern synonyms and you’d not be able to tell of those were real constructors or not.

I’ve not tried implementing this, but I think SHE has something like it.
",simonpj
3,5777,84,"ross, ben@…, benjamin.moseley@…, abcz2.uprola@…",core lint error with arrow notation and GADTs,Compiler,7.4.2,7.6.2,ross,new,normal,2013-03-04T01:43:32-0800,"The following code panics GHC (with 7.0.3, 7.2 and 7.4.0.20111219):

{{{
{-# LANGUAGE Arrows, GADTs #-}
import Control.Arrow

data Value a where BoolVal :: Value Bool

class ArrowInit f where
    arrif :: f b -> ()

instance ArrowInit Value where
    arrif = proc BoolVal -> returnA -< ()
    -- arrif = arr (\BoolVal -> ())
}}}

I am attaching the -dcore-lint from 7.4.
",benmos
5,917,84,"prokhorenkov@…, pho@…, mail@…, ezyang@…",-O introduces space leak,Compiler,6.5,_|_,,new,lowest,2012-09-26T00:19:41-0700,"consider the following variant of a popular space problem
{{{
initlast :: (()->[a]) -> ([a], a)
initlast xs = (init (xs ()), last (xs ()))

main = print $ case initlast (\()->[0..1000000000]) of
                 (init, last) -> (length init, last)
}}}

the long list has been wrapped in abstractions to avoid
sharing, gaining constant space processing rather than
the space leak in the original code - see

http://www.haskell.org/pipermail/haskell-cafe/2006-September/018447.html

http://www.haskell.org/pipermail/haskell-cafe/2006-September/018464.html

this works nicely if compiled without -O, but unfortunately,
-O reintroduces the space leak (apparently lifting and sharing
the common and space-expensive subexpression).

1. I didn't see a ticket for this issue, so I wanted to record the example

2. avoiding sharing isn't always possible, so it would be nice if one could 
""bypass"" sharing in such cases. in the old g-machine, that might have 
been as simple as introducing a pragma that tells the compiler to omit
the update after the eval in the code for some subexpression (so the
original application node would not be overwritten by the space-expensive
result, trading time for space). is there a chance for a similar trick
in GHC? so one might write code like this (handwaving:-):
{{{
initlast :: [a] -> ([a], a)
initlast xs = (init ({-# COPY #-} xs), last ({-# COPY #-} xs))

main = print $ case initlast [0..1000000000] of
                 (init, last) -> (length init, last)
}}}",claus.reinke@…
4,4101,83,"alexey.skladnoy@…, bjornbm, anton.nik@…, carter.schonwald@…",Primitive constant unfolding,Compiler,6.12.2,7.6.2,,new,low,2013-04-21T10:38:01-0700,"Examining the core generated by ghc with -O2 on a numerical code, I saw things like :
{{{
case GHC.Prim.<## x_aB9 (GHC.Prim.**## 2.0 -1021.0) of _  {...
}}}
This code being executed each time my code performs an addition ! GHC does not seem to unfold the constants right with at least **##. By the way, it should definitely be possible to specify a Double# constant in hexadecimal.",malosh
4,5202,82,"daniel.is.fischer@…, johan.tibell@…, mihai.maruseac@…",Docs on strictness info out of date,Documentation,7.0.3,7.6.2,,new,low,2012-09-12T04:13:29-0700,"http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/faster.html section “How do I find out a function's strictness?”

The one inaccuracy I noticed is that we no longer output P for primitive (primitive types seem to be confusingly given L!); I believe the docs are a hold-over from the old strictness analyzer. Someone better acquainted with the strictness analyzer should give it a lookover.",ezyang
2,4364,81,"jakewheatmail@…, pho@…, hackage.haskell.org@…, awson",Template Haskell: Cycle in type synonym declarations,Compiler (Type checker),7.1,7.8.1,simonpj,new,high,2013-03-22T11:32:01-0700,"`type-level-numbers-0.1` doesn't build with 7.0.1 RC 1. Here's the essence:

{{{
{-# LANGUAGE TemplateHaskell #-}
module Q where

data Z

type N0 = $( [t| Z |] )
type N1 = $( [t| Z |] )
}}}

{{{
$ ghc --make m.hs
[1 of 1] Compiling Q                ( m.hs, m.o )

m.hs:7:1:
    Cycle in type synonym declarations:
      m.hs:7:1-23: type N0 = $([t| Z |])
      m.hs:8:1-23: type N1 = $([t| Z |])
}}}
",igloo
3,4470,81,"choener@…, pumpkingod@…, michal.terepeta@…, dterei",Loop optimization: identical counters,Compiler,,7.6.2,,new,normal,2012-09-12T04:12:00-0700,"Consider the small program below, where 'f' has to counters 'i' and 'j'. Both are completely identical; the only difference is that 'i' is used to change 's', while 'j' changes 'm'. It would be beneficial to have GHC transform 'f' into something like 'ff' so that one register less is required.

Neither GHC nor LLVM perform this optimization.

Code of this kind occurs when one uses the ""vector library"". See this discussion: [http://www.haskell.org/pipermail/glasgow-haskell-users/2010-November/019446.html]

{{{
{-# LANGUAGE BangPatterns #-}

module Main where

import Criterion.Main

f :: Int -> Int -> Int -> Int -> Int
f !i !j !s !m
  | i == 0    = s+m
  | otherwise = f (i-1) (j-1) (s + i+1) (m + j*5)

g :: Int -> Int
g !k = f k k 0 0


ff :: Int -> Int -> Int -> Int
ff !i !s !m
  | i == 0    = s+m
  | otherwise = ff (i-1) (s + i+1) (m + i*5)

gg :: Int -> Int
gg !k = ff k 0 0



{-
main = do
  print $ g 20
  print $ gg 20
-}

main = defaultMain
  [ bench "" g"" $ whnf g  20 -- 67.9ns
  , bench ""gg"" $ whnf gg 20 -- 64.5ns
  ]
}}}

Function 'f' produces this core:
{{{
$wf =
  \ (ww_s1uU :: Int#)
    (ww1_s1uY :: Int#)
    (ww2_s1v2 :: Int#)
    (ww3_s1v6 :: Int#) ->
    case ww_s1uU of wild_B1 {
      __DEFAULT ->
        $wf
          (-# wild_B1 1)
          (-# ww1_s1uY 1)
          (+# (+# ww2_s1v2 wild_B1) 1)
          (+# ww3_s1v6 (*# ww1_s1uY 5));
      0 -> +# ww2_s1v2 ww3_s1v6
    }
}}}

'wild_B1' and 'ww1_s1uY' should be merged in this case.

The attached source is above program.",choenerzs
3,2917,81,"lennart@…, danieldiaz@…, ghc@…, dterei",alloca and allocaArray do not respect alignment,Compiler (FFI),6.12.3,_|_,,new,normal,2011-05-04T18:28:50-0700,"When allocating memory with alloca or allocaArray the alignment of the Storable is not respected, alignment seems to be on 8 byte boundary. malloc and mallocArray seem to have the same problem.  And because of this functions like withArray etc also break the alignment restriction of the array element.

Run this and look at the pointer.
{{{
import Foreign.Ptr
import Foreign.Storable
import Foreign.Marshal.Array
import Foreign.Marshal

data Foo = Foo

instance Storable Foo where
    sizeOf _ = 8
    alignment _ = 256

main =
    allocaArray 5 $ \ p -> do
    let _ = p :: Ptr Foo
    print p
    q <- mallocArray 5
    let _ = q :: Ptr Foo
    print q
}}}
",guest
4,2356,81,"lennart@…, chak@…, mjm2002@…, leather@…",GHC accepts multiple instances for the same type in different modules,Compiler,6.8.3,_|_,,new,low,2013-01-27T11:06:00-0800,"as mentioned by Simon PJ in this thread:

http://www.haskell.org/pipermail/haskell/2008-June/020436.html

here is the example, spelled out:
{{{
module B0 where
class C a where c :: a -> String
data T = T deriving Show

module B1 where
import B0
instance C T where c _ = ""B1""
b = c T

module B2 where
import B0
instance C T where c _ = ""B2""
b = c T

module Main where
import B1
import B2
main = print (B1.b,B2.b)
}}}
this is accepted without flags or errors and prints `(""B1"",""B2"")`.

the [http://haskell.org/onlinereport/decls.html#sect4.3.2 language report, section 4.3.2] clearly states:

  A type may not be declared as an instance of a particular class more than once in the program.
",claus
3,2132,79,"v.dijk.bas@…, hackage.haskell.org@…, carter.schonwald@…",Optimise nested comparisons,Compiler,6.8.2,_|_,,new,normal,2013-04-21T10:38:16-0700,"GHC isn't capable of this optimisation:
{{{
  case (x ># y) of             ==>    case (x ># y) of
    True -> ...(x ==# y)...               True -> ...False...
    False -> ...                          False -> ...
}}}
That is, knowing that (x>y) we know that the two are not equal.

Also, consider this:
{{{
  case (x ># y) of               ==>   case (x >=# y) of
     True -> e                           True -> e
     False -> case (x ==# y) of          False -> e'
                True -> e
                False -> e'
}}}
Again this needs special knowlege about comparison operators.  However, it ''does'' arise.  Consider this:
{{{
  data T = MkT Int deriving( Eq, Ord )
}}}
The derived `(>)` operation looks like this:
{{{
Foo.$dm> =
  \ (eta_a8q :: Foo.T) (eta1_a8r :: Foo.T) ->
    case eta_a8q of wild_B1 { Foo.MkT a1_a60 ->
    case eta1_a8r of wild1_XO { Foo.MkT b1_a62 ->
    case a1_a60 of wild2_a9I { GHC.Base.I# x#_a9K ->
    case b1_a62 of wild11_a9M { GHC.Base.I# y#_a9O ->
    case GHC.Prim.<# x#_a9K y#_a9O of wild3_a9W {
      GHC.Base.False ->
        case GHC.Prim.==# x#_a9K y#_a9O of wild12_a9Z {
          GHC.Base.False -> GHC.Base.True; GHC.Base.True -> GHC.Base.False
        };
      GHC.Base.True -> GHC.Base.False
}}}
See also #2130",simonpj
3,1544,77,"koen@…, doaitse@…, malcolm@…, emlempsi@…",Derived Read instances for recursive datatypes with infix constructors are too inefficient,Compiler,6.6.1,7.6.2,,new,normal,2013-01-23T08:21:50-0800,"Consider this definition:
{{{
data Exp = C | Exp :+: Exp | Exp :-: Exp deriving ( Read, Show )
}}}
Now, try something like:
{{{
> read ""((((((((((C))))))))))"" :: Exp
}}}
Even this simple expression may take several seconds to parse. It gets worse if you keep adding parenthesis. And even worse if you add more infix constructors....",jcpetruzza@…
3,4347,75,"ganesh, chowells79@…, dimitris@…, p.giarrusso@…",Bug in unification of polymorphic and not-yet-polymorphic type,Compiler (Type checker),7.1,7.6.2,,new,normal,2012-09-12T04:12:00-0700,"The new type checker in GHC 7 seems to reject some cases of impredicative instantiation that prior versions allowed. I was initially alerted to this by Simon Marlow, who sent a patch for vector-algorithms removing a use of {{{($)}}} where it would have to be instantiated impredicatively.

Initially, I thought this was due to a planned removal of impredicativity, but this cannot be the case, because:

{{{
const :: a -> (forall b. b) -> a
}}}

is accepted by the type checker. However, the simple:

{{{
id :: (forall a. a) -> (forall b. b)
}}}

is not, giving an error message:

{{{
    Couldn't match type `b' with `forall a. a'
      `b' is a rigid type variable bound by
          an expression type signature at <interactive>:1:32
    In the expression: id :: (forall a. a) -> (forall b. b)
}}}

This would seem to indicate that the type is being rewritten to:

{{{
forall b. (forall a. a) -> b
}}}

and then the {{{forall a. a}}} matched with the bare {{{b}}}. It is, of course, fine to rewrite the type this way, since the two are isomorphic, but it is unfortunate that it causes the checker to reject what would otherwise be a valid instantiation.",dolio
3,2427,74,"gwern0@…, id@…, nathanhowell@…",Allow compilation of source from stdin,Compiler,6.8.3,_|_,,new,normal,2013-02-22T17:43:28-0800,"Hiya. So, as part of how the Hint library (a wrapper around the GHC API operates), it has to generate a file in /tmp containing module boilerplate and the supplied code of interesting, and it then evaluates it*. But for my mueval code (which uses Hint), I'd like to disable file creation entirely through resource limits, and so it would be much better for Hint if it could instead just create the string and pipe it right into GHC. This avoids any file creation (which may not be possible for any number of reasons besides resource limits, like LiveCDs or read-only disks). But in my experiments, and those of #haskell, GHC determinedly blocks any attempt - you can't simply pipe it in with |, you can't use /dev/stdin, can't use one of the file descriptors, etc.

So what I would like is to be able to do:
{{{
$ echo ""import qualified Data.List\nmain = print $ Data.List.intersperse 'f' ""ggggg""

""fgfgfgfgfgfg""
}}}
(Why can't I use ghc -e? Doesn't do imports of any kind, and if mueval is to replicate lambdabot's functionality, it needs to be able to import many libraries qualified.**)

* It has to do this roundabout hackish thing because alas, the GHC API seems to allow functions from any module whatsoever to be called as long as they are named qualified, even if the appropriate module had not been allowed in. The magnitude of this as a security hole is obvious.

** Why qualified? Too many of the basic libraries have name collisions. Can't remove them, as it'd be silly to have only half the base libraries or whatever, but can't just blindly import them as you'll get conflicts.",guest
3,728,72,"Bulat.Ziganshin@…, SamB, pho@…, anton.nik@…",switch to compacting collection when swapping occurs,Runtime System,6.4.1,_|_,,new,normal,2013-06-12T00:18:03-0700,"One avenue for tuning the GC to work better in low memory conditions is for it to auto-switch to compacting collection when swapping is happening.  We can detect swapping using {{{getrusage()}}} on Unix systems.  See:

[http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009863.html]",simonmar
4,4471,72,"ekmett@…, dagitj@…, simon@…, shelarcy@…",Incorrect Unicode output on Windows Console,Compiler,6.12.3,7.6.2,,new,low,2013-03-07T23:44:36-0800,"To reproduce,

 * start a windows console
 * Change the console's font to a ttf unicode font, like ""Lucida Console"".
 * Type ""chcp 65001"" to set it to the UTF-8 code page.

test.hs
{{{
main = putStrLn ""∷⇒∀→←⋯⊢""
}}}

Output to the console is garbled. `runghc test.hs`:
{{{
∷⇒∀→←⋯⊢
→←⋯⊢
⋯⊢
∷⇒∀→←⋯⊢→←⋯⊢←⋯⊢⋯⊢⊢⊢⊢<stdout>: hFlush: permission denied (Permission denied)
}}}

Piping works correctly. `runghc test.hs > output && type output`:
{{{
∷⇒∀→←⋯⊢
}}}

ghci fails. `ghci test.hs`
{{{
GHCi, version 6.12.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.
Loading package ffi-1.0 ... linking ... done.
[1 of 1] Compiling Main             ( test.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
∷*** Exception: <stdout>: hPutChar: permission denied (Permission denied)
*Main>
}}}",sankeld
4,4466,71,"wren@…, sweirich@…, mail@…",Add extension for type application,Compiler,6.12.3,7.6.2,,new,low,2013-04-30T11:40:04-0700,"
In
http://www.haskell.org/pipermail/libraries/2010-October/014761.html
we discussed adding an extension for explicit type application.

The main stumbling block is syntax.

For example, we would like to be able to write something to the effect of
{{{
(Just @ Char) 'a'
}}}
and also to be able to pattern match types, e.g.
{{{
f ((Just @ t) x) = (Right @ String @ t) x
}}}

For a more useful example:
{{{
data T where
    MkT :: forall a. a -> (a -> Int) -> T

f (MkT @ a x g) = g (x::a)
}}}

Possible suggested syntaxes to make something of type
{{{
Maybe (forall a. a->a)
}}}
were:
{{{
Just @ (forall a. a->a) id    (@ has another meaning in patterns)
Just[forall a. a->a] id       (pvs, opal, HasCASL with paramterized modules; conflicts with Haskell list syntax)
Just {forall a. a->a} id      (Agda)
#Just (forall a. a->a) id
@Just (forall a. a->a) id     (coq)
}}}

In the last 2 cases we would presumably have something like
{{{
Just :: forall a . a -> Maybe a
Just :: Char -> Maybe Char
#Just :: /\ a . a -> Maybe a
#Just Char :: Char -> Maybe Char
}}}
and similarly
{{{
#map :: /\ a b . (a -> b) -> [a] -> [b]
}}}
",igloo
5,2721,71,"tom.schrijvers@…, illissius@…, acfoltzer@…",Newtype deriving doesn't work with type families,Compiler,6.10.1,7.6.2,,new,lowest,2012-09-12T04:14:03-0700,"This assumes `-XTypeFamiles -XGeneralizedNewtypeDeriving`. Example:
{{{
class C a where
  type T a
  foo :: a -> T a

instance C Int where
  type T Int = Int
  foo = id

newtype N = N Int deriving(C)
}}}
This happily produces an `instance C N` but no `type instance T N`. It should either (preferably) generate
{{{
type instance T N = Int
}}}
or fail. The example also compiles if `T` is a data family (the `Int` instance needs to be change accordingly). It should probably fail in this case.

BTW, this also compiles fine, with rather dramatic consequences:
{{{
type family T a
class C a where
  foo :: a -> T a

type instance T Int = Int
instance C Int where
  foo = id

type instance T N = Double
newtype N = N Int deriving(C)
}}}
I guess this last example is the same bug as #1496. I wonder if the deriving clause could generate something like:
{{{
instance T Int ~ T N => C Int
}}}

",rl
2,6147,68,"bos@…, bgamari@…, hackage.haskell.org@…",GeneralizedNewtypeDeriving should fail with data families,Compiler (Type checker),7.2.1,7.8.1,simonpj,new,high,2013-03-25T18:36:34-0700,"Here is an example:

{{{
{-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies #-}
module Foo where

data family T a
data instance T Int = T_Int Int

class C a where
  foo :: a -> T a

instance C Int where
  foo = T_Int

newtype Foo = Foo Int deriving(C)
}}}

The `deriving(C)` clause on `Foo` should fail but instead it derives an instance which can't possible be correct since there is no corresponding `data instance T Foo`. This is closely related to #2721 (where newtype deriving was disabled in the presence of associated types) but much more difficult to test for. Probably also related to #1496.",rl
3,806,68,"Bulat.Ziganshin@…, Deewiant, ryani, Olathe, dagitj@…",hGetBufNonBlocking doesn't work on Windows,libraries/base,6.4.2,_|_,,new,normal,2013-03-02T21:06:40-0800,"All HAppS (http://happs.org/HAppS/README.html) applications fail with an internal error: asyncRead# when compiled with the  -threaded option.

To reproduce the error:
- compile any of the apps in the example subdirectory with -threaded and access it over the net (http://localhost:8000).

For example: 

ghc --make -v -fallow-overlapping-instances -fglasgow-exts -threaded httpd.hs -o httpd

The same programs compiled without -threaded work fine.

Tested on Windows XP with latest SP/patches and gcc 6.4.2.
 
Let me know if you would like more info or the full compilation trace.",titto@…
4,4459,68,"haskell.vivian.mcphail@…, mmitar@…, leather@…",Polymorphic Data.Dynamic,GHC API,7.1,7.6.2,vivian,new,low,2012-09-12T04:12:32-0700,"At some point in the compilation process an expression acquires a fully-specified, possibly polymorphic, type.  If we add an operation that join that type and that expresssion, say `TypedAny`, then we can implement the part of #4316 requested by mitar.

In GHCi we can evaluate `HValue`s '''and also''' string them together with `bind` statements.

The function
{{{
applyDynamic :: TypedAny -> TypedAny -> Maybe TypedAny
}}}
includes in its implementation a dictionary lookup and possible dynamic object linking for class methods.

the function
{{{
fromDynamic :: TypedAny -> Maybe a
}}}
like `applyDynamic`, runs the typechecker at runtime to unify (and possibly link) the dynamic type (!TypedAny) and the static type (a).

''Conjecture '' Since we already have `typecase` (classes), with type families, this feature provides/simulates dependent types.",vivian
3,2301,67,"bos@…, tibbe, pho@…, v.dijk.bas@…",Proper handling of SIGINT/SIGQUIT,libraries/process,6.12.3,7.6.2,,new,normal,2013-01-27T10:55:19-0800,"This guide http://www.cons.org/cracauer/sigint.html suggests a couple things that we should do that we do not currently do.

It comes in two parts.
 1. how we respond to our own calling process when we terminate due to `^C`
 1. how we respond to process that we call terminating due to `^C`

The first part is easier. If we decide that we want to terminate in response to a `^C` signal then it is important that our calling process knows that. We must kill ourselves using `SIGINT` and not just terminate via `exit()` otherwise our calling process must assume that we decided to ignore the `^C`. We should use `killpid(getpid(),SIGINT)`.

Of course we may well want to catch `^C` and do cleanup work by unwinding all exception handlers etc. It is therefore important to distinguish `^C` from other exceptions so that when the `^C` exception propagates to the top level exception handler we have enough information to know to use `killpid(getpid(),SIGINT)` rather than just `exit(1)`. So we should add an `Interrupted` case to the `Exception` type.

How we respond to `^C` while running sub-processes is more subtle. If we are delegating interaction with the user via the controlling terminal then we should also delegate the decision about how to respond to `^C`. Some child processes will also want to take cleanup action on `^C` or ignore it completely (eg ghci) so it is not right for us the parent process to catch `^C` and decide what to do. So where we are delegating the decision we should ignore `^C`.

When we wait for a child process to terminate and discover that it exited due to `SIGINT` then at that moment we should respond in the same way as if we ourselves had received a `^C`. A sensible default might be to send the `Interrupted` exception to every thread in the system, or at least to the main thread. A haskell program can always change the response to `^C` by using `installHandler` (eg for an interactive REPL program like ghci).",duncan
3,6037,67,"pho@…, dagitj@…, hackage.haskell.org@…",Compile-time crash with sources with non-representable unicode characters,Compiler,7.4.1,7.8.1,,new,normal,2013-03-22T02:57:23-0700,"The following file causes GHC to crash, if compiled in the ""C"" locale.

{{{
$ LC_ALL=C ghc unicode.hs
[1 of 1] Compiling Foo              ( unicode.hs, unicode.o )

unicode.hs:2:1:
    Warning: Pattern match(es) are overlapped
             In an equation for `<stderr>: hPutChar: invalid argument (invalid character)
}}}

unicode.hs:
{{{
module Foo where
δ x = 3
δ x = 4
}}}",akio
3,595,67,"marcot@…, ryani.spam@…, benjross@…",Overhaul GHC's overlapping/non-exhaustive pattern checking,Compiler,None,_|_,,new,normal,2012-03-27T01:50:03-0700,"GHC has a module in the desugarer (Check) which checks whether patterns are overlapping and/or exhaustive, to support the flags -fwarn-overlapping-patterns and -fwarn-non-exhaustive-patterns.  The code is old and crufty, and has several outstanding bugs.  A rewrite is needed.",simonmar
5,1365,67,"simonmar@…, mnislaih@…, SamB, mjm2002@…",-fbyte-code is ignored in a OPTIONS_GHC pragma,GHCi,6.6.1,7.6.2,,new,lowest,2012-09-12T04:13:36-0700,"When loading a bunch of modules in ghci with ''-fobject-code'', it seems reasonable to be expect that individual ''GHC_OPTIONS -fbyte-code'' pragmas will have the effect of loading individual modules via the bytecode backend.",mnislaih
2,5610,66,"ghc@…, bos@…, malaquias@…","Improve ""Unacceptable argument type in foreign declaration"" error message",Compiler (Type checker),7.6.1-rc1,7.4.1,,new,high,2012-09-18T02:18:53-0700,"Using ghc 1ece7b27a11c6947f0ae3a11703e22b7065a6b6c, zlib fails to build,

{{{
$ cabal install zlib
Resolving dependencies...
Configuring zlib-0.5.3.1...
Preprocessing library zlib-0.5.3.1...
Building zlib-0.5.3.1...
[1 of 5] Compiling Codec.Compression.Zlib.Stream ( dist/build/Codec/Compression/Zlib/Stream.hs, dist/build/Codec/Compression/Zlib/Stream.o )

Codec/Compression/Zlib/Stream.hsc:857:1:
    Unacceptable argument type in foreign declaration: CInt
    When checking declaration:
      foreign import ccall unsafe ""static zlib.h inflateInit2_"" c_inflateInit2_
        :: StreamState -> CInt -> Ptr CChar -> CInt -> IO CInt

Codec/Compression/Zlib/Stream.hsc:857:1:
    Unacceptable argument type in foreign declaration: CInt
    When checking declaration:
      foreign import ccall unsafe ""static zlib.h inflateInit2_"" c_inflateInit2_
        :: StreamState -> CInt -> Ptr CChar -> CInt -> IO CInt

Codec/Compression/Zlib/Stream.hsc:857:1:
    Unacceptable result type in foreign declaration: IO CInt
    Safe Haskell is on, all FFI imports must be in the IO monad
    When checking declaration:
      foreign import ccall unsafe ""static zlib.h inflateInit2_"" c_inflateInit2_
        :: StreamState -> CInt -> Ptr CChar -> CInt -> IO CInt

Codec/Compression/Zlib/Stream.hsc:865:1:
    Unacceptable argument type in foreign declaration: CInt
    When checking declaration:
      foreign import ccall unsafe ""static zlib.h inflate"" c_inflate
        :: StreamState -> CInt -> IO CInt

Codec/Compression/Zlib/Stream.hsc:865:1:
    Unacceptable result type in foreign declaration: IO CInt
    Safe Haskell is on, all FFI imports must be in the IO monad
    When checking declaration:
      foreign import ccall unsafe ""static zlib.h inflate"" c_inflate
        :: StreamState -> CInt -> IO CInt

Codec/Compression/Zlib/Stream.hsc:872:1:
    Unacceptable argument type in foreign declaration: CInt
    When checking declaration:
      foreign import ccall unsafe ""static zlib.h deflateInit2_"" c_deflateInit2_
        :: StreamState
           -> CInt
              -> CInt -> CInt -> CInt -> CInt -> Ptr CChar -> CInt -> IO CInt

Codec/Compression/Zlib/Stream.hsc:872:1:
    Unacceptable argument type in foreign declaration: CInt
    When checking declaration:
      foreign import ccall unsafe ""static zlib.h deflateInit2_"" c_deflateInit2_
        :: StreamState
           -> CInt
              -> CInt -> CInt -> CInt -> CInt -> Ptr CChar -> CInt -> IO CInt

Codec/Compression/Zlib/Stream.hsc:872:1:
    Unacceptable argument type in foreign declaration: CInt
    When checking declaration:
      foreign import ccall unsafe ""static zlib.h deflateInit2_"" c_deflateInit2_
        :: StreamState
           -> CInt
              -> CInt -> CInt -> CInt -> CInt -> Ptr CChar -> CInt -> IO CInt

Codec/Compression/Zlib/Stream.hsc:872:1:
    Unacceptable argument type in foreign declaration: CInt
    When checking declaration:
      foreign import ccall unsafe ""static zlib.h deflateInit2_"" c_deflateInit2_
        :: StreamState
           -> CInt
              -> CInt -> CInt -> CInt -> CInt -> Ptr CChar -> CInt -> IO CInt

Codec/Compression/Zlib/Stream.hsc:872:1:
    Unacceptable argument type in foreign declaration: CInt
    When checking declaration:
      foreign import ccall unsafe ""static zlib.h deflateInit2_"" c_deflateInit2_
        :: StreamState
           -> CInt
              -> CInt -> CInt -> CInt -> CInt -> Ptr CChar -> CInt -> IO CInt

Codec/Compression/Zlib/Stream.hsc:872:1:
    Unacceptable argument type in foreign declaration: CInt
    When checking declaration:
      foreign import ccall unsafe ""static zlib.h deflateInit2_"" c_deflateInit2_
        :: StreamState
           -> CInt
              -> CInt -> CInt -> CInt -> CInt -> Ptr CChar -> CInt -> IO CInt

Codec/Compression/Zlib/Stream.hsc:872:1:
    Unacceptable result type in foreign declaration: IO CInt
    Safe Haskell is on, all FFI imports must be in the IO monad
    When checking declaration:
      foreign import ccall unsafe ""static zlib.h deflateInit2_"" c_deflateInit2_
        :: StreamState
           -> CInt
              -> CInt -> CInt -> CInt -> CInt -> Ptr CChar -> CInt -> IO CInt

Codec/Compression/Zlib/Stream.hsc:884:1:
    Unacceptable argument type in foreign declaration: CInt
    When checking declaration:
      foreign import ccall unsafe ""static zlib.h deflate"" c_deflate
        :: StreamState -> CInt -> IO CInt

Codec/Compression/Zlib/Stream.hsc:884:1:
    Unacceptable result type in foreign declaration: IO CInt
    Safe Haskell is on, all FFI imports must be in the IO monad
    When checking declaration:
      foreign import ccall unsafe ""static zlib.h deflate"" c_deflate
        :: StreamState -> CInt -> IO CInt
cabal: Error: some packages failed to install:
zlib-0.5.3.1 failed during the building phase. The exception was:
ExitFailure 1
}}}",bgamari
3,5075,66,"tkn.akio@…, danielv@…, nfrisby@…",CPR optimisation for sum types if only one constructor is used,Compiler,7.0.3,7.6.2,simonpj,new,normal,2013-04-28T07:14:53-0700,"Inspired by #3138, it might be useful for StrAnal to detect functions such as the following where only one of the data constructors for a sum type are CPRed:

{{{
loop x = case x < 10 of True -> Left x; False -> loop (x*2)
}}}

We can usefully transform to:

{{{
$wloop x = case (case x < 10 of True -> Left x; False -> loop (x*2)) of Left y -> (# y #)
loop x = case loop x of (# y #) -> Left y
}}}

Attached patch implements this behaviour. Most of the complication in the new code occurs because adding a DataCon field to the Demand data type means that we have to define a separate IfaceDemand type for storage in interface files.

The patch validates but I haven't done any tests on nofib. I have confirmed that the new optimisation hits on some examples, though.",batterseapower
5,3070,66,"squadette@…, mihai.maruseac@…, anton.nik@…",floor(0/0) should not be defined,Prelude,6.10.1,7.6.2,squadette,new,lowest,2012-09-12T04:14:08-0700,"floor(0/0) returns some giant negative integer - it should return NaN or undefined.

The bug appears to be in some implementation of 'properFraction' in the standard library.

[from Andrej Bauer, from Barak Pearlmutter (from ???)]",carette
3,1965,65,"pumpkingod@…, ireney.knapp@…, mokus@…",Allow unconstrained existential contexts in newtypes,Compiler,6.8.1,7.6.2,,new,normal,2012-09-12T04:11:57-0700,"Declarations like

{{{
newtype Bar = forall a. Bar (Foo a)
}}}

ought to be allowed so long as no typeclass constraints are added. Right now, this requires data rather than newtype.
",guest
3,3353,65,"proppy@…, barsoap@…, hackage.haskell.org@…",Add CLDouble support,Compiler,6.12.1,_|_,,new,normal,2012-08-01T20:59:54-0700,"The FFI spec says that we should support `CLDouble`, but we don't (#2793).
",igloo
3,7623,64,"dterei, karel.gardas@…, 0@…, mad.one@…",GHC Arm support,Compiler,7.7,7.8.1,,new,normal,2013-04-12T16:04:04-0700,Top level to track some important fixes for proper ARM support of GHC.,dterei
4,4846,64,"emax@…, sweirich@…, dimitris@…",Newtype derving used wrongly,Compiler,7.0.1,7.6.2,,new,low,2012-09-12T04:13:23-0700,"Emil Axelsson reports: I attach a program `Test.hs` which I suspect demonstrates a bug in GHC. The important lines are:
{{{
   showType :: forall a . Expr a -> String
   showType (Lit _) = show (typeOf (undefined :: a))

   test1 = showType (mk     :: Expr BOOL) -- Prints ""Bool"" (wrong?)
   test2 = showType (Lit mk :: Expr BOOL) -- Prints ""Main.BOOL"" (correct)
}}}
`test1` and `test2` give different results, even though showType shouldn't be able to tell them apart. It seems that the `Typeable` context packed with the Lit constructor is wrong in `test2`.

",simonpj
5,3065,64,"bertram.felgenhauer@…, kr.angelov@…, dterei",Reorder tests in quot to improve code,libraries/base,6.10.1,7.6.2,,new,lowest,2012-09-12T04:14:08-0700,"[SLPJ: capturing an email thread in a ticket]

Krasimir Angelov found that this function:
{{{
a `quot` b
    | b == 0                     = divZeroError
    | a == minBound && b == (-1) = overflowError
    | otherwise                  =  a `quotInt` b
}}}
is expanded to:
{{{
a `quot` b =
   if b == 0
     then divZeroError
     else if a == minBound
              then if b == (-1)
                       then overflowError
                       else a `quotInt` b
              else a `quotInt` b
}}}
Then the compiler sees that b is a constant and computes that b == 0
is False and b == (-1) is also False so it could eliminate two If
statements. The result is:
{{{
a `quot` b =
   if a == minBound
     then a `quotInt` b
     else a `quotInt` b
}}}
and this is exactly what we get. I bet that if the original function was:
{{{
a `quot` b
    | b == 0                     = divZeroError
    | b == (-1) && a == minBound = overflowError   -- Note the changed order here
    | otherwise                  =  a `quotInt` b
}}}
then we would get what we want. I think that it is much more often to
have division where the divisor is known so we will get the best code
in this case.

Shortly afterwards, Bertram Felgenhauer tried it out.  It works, and it has the desired effect. It's not always a win though; the nofib prime sieve benchmark suffers.

For a patch, see
  http://int-e.home.tlink.de/haskell/ghc-libraries-base-tune-division.patch
(SLPJ: I've attached it to the ticket too)

Nofib results extract:
{{{
------------------------------------------------------------------------
        Program           Size    Allocs   Runtime   Elapsed
------------------------------------------------------------------------
           fish          -0.7%     -5.3%      0.05      0.04
         primes          -0.0%    +28.5%    +25.6%    +25.5%
   wheel-sieve2          -0.0%     -0.3%    -17.9%    -18.6%
------------------------------------------------------------------------
            Min          -0.9%     -5.3%    -17.9%    -18.6%
            Max          +0.1%    +28.5%    +25.6%    +25.5%
 Geometric Mean          -0.2%     +0.2%     -0.0%     +0.2%
}}}
'primes' is an outlier - the other slowdowns are below 3%

What happens in 'primes' is that 'mod' no longer gets inlined;
apparently it now looks bigger to the compiler than before.

Using -funfolding-use-threshold=10 brings the benchmark back to its
original speed, despite the extra comparison before doing the
division.

In 'wheel-sieve2', the first different optimization choice I see is
again a 'mod' that is no longer inlined; this leads to a change in other
inlining choices that result in a speedup for reasons that I have not
investigated.


",simonpj
5,1420,64,"lennart.augustsson@…, claudiusmaximus@…",Automatic heap profile intervals,Profiling,6.7,7.6.2,,new,lowest,2012-09-12T04:13:37-0700,"When doing heap profiling it is sometimes hard to know what a good sampling interval is.  Make it too small and it takes forever, make it too coarse and the resolution is bad.
In hbc the default setting was to automatically adjust the interval.  It starts out very small, but as samples accumulate it gets larger and larger.  This is a nice compromise.",guest
4,3844,63,"mmitar@…, hackage.haskell.org@…, ezyang@…",Undeprecate #include (in at least some circumstances),Compiler (FFI),6.12.1,7.6.2,,new,low,2012-09-12T04:12:21-0700,"The attached program generates a warning: ""Warning: -#include is deprecated: No longer has any effect"". However, if I remove the #include, it fails to compile with:


{{{
Fixes.hsc: In function ‘main’:
Fixes.hsc:29: error: ‘SOL_SOCKET’ undeclared (first use in this function)
Fixes.hsc:29: error: (Each undeclared identifier is reported only once
Fixes.hsc:29: error: for each function it appears in.)
Fixes.hsc:29: error: ‘SO_LINGER’ undeclared (first use in this function)
Fixes.hsc:37: error: invalid application of ‘sizeof’ to incomplete type ‘struct linger’ 
Fixes.hsc:40: error: invalid use of undefined type ‘struct linger’
Fixes.hsc:41: error: invalid use of undefined type ‘struct linger’
}}}

Evidently it's not quite true that #include no longer has any effect.",cjs
4,5298,63,"hackage.haskell.org@…, pho@…, jpm@…",Inlined functions aren't fully specialised,Compiler,7.0.3,7.6.2,,new,low,2012-09-12T04:13:31-0700,"When a function is inlined, it can expose other functions as candidates for specialisation, but GHC doesn't specialise them.

For instance, given the two modules

{{{
module A where

{-# INLINABLE fac #-}
fac :: Num a => a -> a
fac 0 = 1
fac n = n * fac (n-1)

{-# INLINE f #-}
f :: Num a => a -> a
f a = fac a
}}}


{{{
module B where

import A

g :: Int -> Int
g x = f x
}}}

we see that f is inlined, but fac isn't specialised for Ints:

{{{
B.g :: Int -> Int
[GblId,
 Arity=1,

 Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True,
         ConLike=True, Cheap=True, Expandable=True,
         Guidance=IF_ARGS [0] 30 0}]
B.g =
  \ (x_ary :: Int) ->
    A.fac @ Int $fNumInt x_ary
}}}

Removing the INLINE pragma on f doesn't help.

Either of the following changes will cause fac to be specialised:

 * adding {-# SPECIALISE f :: Int -> Int #-} to module B
 * defining ""g x = fac x"" instead

This happens with both GHC 7.0.3 and GHC HEAD",reinerp
5,2933,63,"ingmar@…, pho@…, karel.gardas@…",LDFLAGS ignored by build system,Build System,6.10.1,7.6.2,,new,lowest,2012-09-12T04:14:05-0700,"I have required libs installed in `/opt/csw/lib` which is not on the ordinary system linker path. This includes things like `libgmp` etc. That means that to link ghc I want to pass `-R/opt/csw/lib` so that at runtime I do not need to set `LD_LIBRARY_PATH`.

The `./configure --help` mentions `LDFLAGS` however this is ignored. When building gcc the equivalent makes everything work out fine. It would be nice if this were supported.

Note also that `--with-gmp-includes` and `--with-gmp-libraries` are only half helpful. They add -L and -I options during the build only. That lets ghc link stuff using gmp. There are still two problems however:

 * Running such programs does not work if the gmp lib dir is not on the standard runtime linker path (which is quite likely given that it was not on the standard compile-time linker path).
 * It does not cause the final built ghc to automatically use -L/path/to/gmp/lib. Again I think if it's using `-L/path/to/gmp/lib` it should also use `-R/path/to/gmp/lib` or it'll link but not run.

Some people claim that -R is evil. If we think it is evil and we choose not to use it for `--with-gmp-includes` and `--with-gmp-libraries` then those two become less than useful and it becomes more important to support `LD_OPTIONS`/`LDFLAGS` properly so that distros like the Solaris CSW can use it. For example, see http://www.opencsw.org/standards/pkg-walkthrough which recommends:
{{{
export LD_OPTIONS='-R/opt/csw/lib/$ISALIST -R/opt/csw/lib -L/opt/csw/lib'
}}}

Note: the workaround is to modify the driver script of the bootstrapping ghc and add `-optl-R/the/extra/lib` and then do the same for the script template that will get used by the stage1/2 inplace and final ghc, or to temporarily use LD_LIBRARY_PATH and modify the final ghc driver script during/after install.",duncan
3,5467,61,"pho@…, sol@…, mail@…",Template Haskell: support for Haddock comments,Template Haskell,7.2.1,7.6.2,,new,normal,2012-12-17T01:47:46-0800,"I would like Template Haskell to be aware of Haddock comments.

Here's a concrete example. The data-accessor-template package (http://hackage.haskell.org/package/data-accessor-template) can be used as follows:

{{{
{-# LANGUAGE TemplateHaskell #-}
module Example where
import Data.Accessor
import Data.Accessor.Template

data MyRecord = MyRecord 
 { field1_ :: Int -- ^ a field
 , field2_ :: Int -- ^ another field
 }

deriveAccessors ''MyRecord
-- produces these:
-- field1, field2 :: Accessor MyRecord Int
}}}

We would like the values {{{field1}}} and {{{field2}}} to inherit the documentation from {{{field1_}}} and {{{field2_}}}, but there is no way to automate this in Template Haskell -- or even to document {{{field1}}} and {{{field2}}} by hand! I would like Template Haskell to support this.

There are two related features required to make this work: firstly, the {{{Dec}}} datatype needs to be extended to support Haddock comments; secondly, {{{reify}}} needs to return these comments. 

I suspect the second feature may require significant plumbing to work in the general case, because I believe that {{{.hi}}} files don't store Haddock comments. A tolerable compromise in this particular example would be to only reify comments for things defined in the current module.

A possible API would be

{{{
data Dec =
  ...
  | DocD Name String -- attach the given docstring to the given name
  | SigD Name Type (Maybe [String]) -- a type signature, with a possibly-empty docstring for each argument and for the result type
  ...
}}}

The {{{DocD}}} constructor is new, but the {{{SigD}}} constructor is unfortunately a modification of the current {{{SigD Name Type}}} constructor. We make this modification to support comments of this form:

{{{
f :: Int   -- ^ The 'Int' argument
  -> Float -- ^ The 'Float' argument
  -> IO () -- ^ The return value
}}}

A possible API for reifying comments would be

{{{
reifyDocs :: Name -> (Maybe String, Maybe [String]) -- documentation string; documentation for individual arguments
}}}

Reiner",reinerp
4,4230,61,"illissius@…, jwlato@…, gmainlan@…",Template Haskell: less type checking in quotations?,Compiler,7.6.3,7.6.2,,new,low,2013-05-09T01:38:34-0700,"This ticket introduces two related Template Haskell design questions.  It's inspired by several other tickets, for which these issues are the underlying cause
 * #4135
 * #4128
 * #4170
 * #4125
 * #4124

-----------------------
= ISSUE 1 =

Consider this module
{{{
  module M where
   import ...
   f x = x
   $(th1 4)
   h y = k y y
   $(th2 10)
}}}
In our present setup we typecheck down to the first splice, run the splice, then typecheck to the second splice, run that, and so on.

But GHC's main structure is: 
 * parse
 * rename (resolve lexical scopes)
 * typecheck

The above setup makes this impossible. We can't even rename the definition of h until we've run the splice $(th1 4) because that might be what brings k into scope.  All this is a bit hard to explain to users.

Now suppose that instead we did the following.  

  * Typecheck and run '''top-level''' splices in the renamer

That is, when the renamer finds a top-level splice:
  * rename it
  * typecheck it
  * run it
  * replace the splice by the result of running it
  * and then rename *that* as if that's what the user had written in the first place
But what about nested quotes?  eg
{{{
     $(th1 [| f x |])
}}}
Well we can't typecheck that quote, because we don't have a type for f and x, because we are in the renamer.  But we don't '''need''' to typecheck the quote to be able to typecheck and run the splice!  Remember, we already have a staging restriction that only imported functions can be '''run''' in a top-level splice.

So the proposal would mean that we don't attempt to typecheck those nested quotes.  Instead they'll be checked after the top-level splice is run, the result spliced in, and the whole shebang typechecked in the context of the program as a whole.
This defers the error message, but not too muce, since typechecking the output of the splice is what will happen next.

This approach would have a number of rather compelling advantages:

 * It would allow us to show the program after renaming and splice
 expansion, but before typechecking.  That's quite helpful.  It
 makes it easier to say that we
   * rename the program, and then
   * typecheck the program
  Remember, GHC is also a Haskell library, and the current
  story (a bit of renaming, a bit of typechecking, then a bit more
  renaming and a bit more typechecking) complicates the API.

 * Geoff Mainland's quasi-quotation mechanism is run in the
   renamer (because it can expand to patterns) so it would make
   all the TH stuff more consistent.

 * Even more exciting, we could support pattern splices, thus
{{{
     f $(g 4) = x+y
}}}
  because the splice $(g 4) would be typechecked and run, perhaps
  expanding to (x,y), say, by the renamer *before* it goes on to
  do scope-analysis on x+y.  This is exactly why quasiquoting
  *can* do pattern splicing at the moment, and TH cannot.
  [[BR]][[BR]]
  This would fix a long-standing infelicity in TH, namely the
  absence of pattern splices.

 * In the same way we could support local declaration
   splices (which are currently ruled out)
{{{
       f x = let $(g [| x |]) in ....
}}}  
 * At the top level we could get rid of the top-to-bottom bias.
   We could allow, say
{{{
     f x = x+x
     $(th [| g |] [| f |])
     g y = y+1
}}}
One disadvantage is that it'd ""bake in"" the staging restriction that a splice can only (typecheck and) run functions imported from another module.  Currently this is only an implementation restriction, which in principle might be lifted.  On the other hand, I have no plans to lift it, and in practice people don't complain about it.

------------------
= ISSUE 2 =

Consider this:
{{{
  f :: Q Type -> Q [Dec]
  f t = [d| data T = MkT $t; 
            g (MkT x) = g+1 |]
}}}
This function f returns a declaration splice, declaring T and g.
You'll see that the constructor MkT takes an argument whose type is passed (as a quotation) to f -- a type splice.

The difficulty is that we can't typecheck the declaration of 'g'
until we know what $t is; and we won't know that until f is called.
So 
 * we can't really typecheck the declaration quote at all

In the case of '''term''' splices in a quotation we can simply give them type (forall a. a), which never gets in the way. But there is no equivalent for *type* splices.  An analogous problem occurs in other declaration splices, for example
{{{
  f t = [d| instance C $t where ... |]
}}}
Here GHC's check that an instance decl is always of form
{{{
   instance C (T a b c)
}}}
falls over, again because we don't know what $t will be.


It's hard to see what to do about this.  

 * We could get rid of type splices (but people like them)

 * We could refrain from typechecking quotations *at all*
   I have users asking me for exactly this: #4125, #4135

 * We could refrain from typechecking *declaration* quotes.
   But the problem still happens for terms
{{{
      [| let { f :: $t; f = e } in .. |]
}}}
 * We could refrain from typechecking any quotation that
   included a type splice.  This is probably the most benign:
   it switches off the type checker just when it's problematic,
   and it's very predictable when that is.  Awkward to implement
   though.
   
Do you have any other ideas?

----------------------
= DISCUSSION =

The two issues are related of course, because both involve doing
less typechecking of quotations.

That seems a pity, because it'd lose one of TH's advantages --
that of typechecking meta programs rather than just typechecking
the output of the meta programs.  And in the case of ISSUE 2,
error messages might get delayed, perhpas to another module
altogether.

However, we deliberately designed TH so that it ''is'' possible to
get a type error when typechecking the result of a type-correct
top-level splice.  Reason: we use type Exp rather than (Exp t) as
in MetaML. That gave us (a lot) more flexibility.  Apart from
anything else, declaration splices would be problematic in the
MetaML approach.

Seen in that light, the proposals here just move a bit further in
the direction of flexibility, at the cost of somewhat-increased
danger of errors being reported later than is ideal.  
",simonpj
3,393,60,"tomasz.zielonka@…, maeder@…, pho@…",functions without implementations,Compiler (Type checker),None,_|_,simonpj,new,normal,2009-11-27T06:58:35-0800,"{{{
Allow to declare a function by only supplying its type
signature.
This feature shall enhance rapid prototyping by fixing
an interface but leaving some functions unimplemented.

Currently this can be (only) simulated by supplying
dummy implementations, like 

f :: ...
f = undefined

Since it is possible to supply dummy data types by
""data T"" (not followed by ""=""), allowing functions
without implementations seems almost to be a logical
consequence. Surely, the compiler should emit warnings
for missing implementations.

It would be nice if such function declarations via type
signatures could be repeated at any position within a
module. 

}}}",c_maeder
3,2041,60,"mjm2002@…, reiner.pope@…, pho@…",Allow splicing in concrete syntax,Template Haskell,6.8.2,_|_,,new,normal,2011-12-16T08:09:52-0800,"
Template Haskell tends to lag behind GHC extensions, so it might be nice to allow concrete syntax to be returned, e.g. something like
{{{
f = $( return (RawE ""5 + 6"") )
}}}
There wouldn't be any need to restrict it to the top level, e.g. this would also be allowed:
{{{
f = $( return (InfixE (IntE 5) '(+) (RawE ""6"")) )
}}}

One possible disadvantage is that it might result in TH languishing even further behind, as there is less incentive to fill in the gaps.

Also, if a module splices in a raw expression from a TH library, what extensions should be enabled when parsing the string? Should we use the extensions enabled for the module, or should the `RawE` constructor specify the extensions to be used? We actually have this problem already, as (for example) when instances are spliced in we might need !OverlappingInstances enabled, so just using the extensions enabled for the module would be consistent.
",igloo
1,7167,59,"jwlato@…, conrad@…, mikezuser@…",Make it a warning (not error) to hide an import that isn't exported,Compiler,7.4.2,7.8.1,igloo,new,highest,2013-06-18T09:49:46-0700,"We often see build failures like
{{{
    Module `Prelude' does not export `catch'
}}}
elicited by an `import` statement
{{{
  import Prelude hiding( catch )
}}}
John Lato and others suggest making this a warning, not an error.  Simon and I agree and we propose to do this for GHC 7.6, thus:

 * Warn, rather than error, when a `hiding` clause mentions something that the module does not export.
 * Suppress with warning with `-fno-warn-dodgy-imports`, an existing warning-suppression flag.
 * Document the change, in the `-fwarn-docugy-imports` flag, and the release notes.

We propose to make this change without a language extension.  Doing so is technically wrong, since H2010 says it's an error to mention something in `hiding` that isn't exported, but it seems too heavyweight to make a language extension just for this; and in any case it would have to be on by default to be any use in practice.

Paolo, can you do all this?  
 * The relevant function is `RnNames.filterImports`.  
 * I suggest you make `lookup_ie` return `TcRn [(LIE Name,AvailInfo)]` rather than the `MaybeErr ...` that it currently returns.
 * The `want_hiding` flag is `True` if this is a hiding clause; in that case `bad_ie` should warn (unless the warning is suppressed) rather than error.",simonpj
4,4288,59,"bos@…, mmitar@…, p.giarrusso@…",Poor -fspec-constr-count=n warning messages,Compiler,6.13,7.6.2,,new,low,2012-09-12T04:12:29-0700,"The attached file, compiled with
{{{
ghc -O2 -fspec-constr-count=5 -c q.hs
}}}
gives a number of messages like
{{{
SpecConstr
    Function `$j_X1BO{v} [lid]'
      has one call pattern, but the limit is 0
    Use -fspec-constr-count=n to set the bound
    Use -dppr-debug to see specialisations
SpecConstr
    Function `$j_X1BR{v} [lid]'
      has two call patterns, but the limit is 1
    Use -fspec-constr-count=n to set the bound
    Use -dppr-debug to see specialisations
}}}
Note that the limit doesn't match the `spec-constr-count` we set.

The ""limit"" given is `sc_count`, but `decreaseSpecCount` changes `sc_count` from its default of `specConstrCount dflags`. However, if this was fixed then we would get even stranger messages like
{{{
      has two call patterns, but the limit is 5
}}}
",igloo
2,7574,58,"pho@…, mle+hs@…, roma@…",Register allocator chokes on certain branches with literals,Compiler (NCG),7.7,7.8.1,thoughtpolice,new,high,2013-05-04T15:26:08-0700,"
While running the test for #7571 (test is in #7573,) under '''WAY=normal''' instead of '''WAY=llvm''', I encountered this bug in the native backend:

{{{

=====> T7571(normal) 6 of 6 [0, 0, 0]
cd . && '/Users/a/code/haskell/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7571.cmm   -no-hs-main   >T7571.comp.stderr 2>&1
Compile failed (status 256) errors were:
ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 7.7.20130113 for x86_64-apple-darwin):
	allocateRegsAndSpill: Cannot read from uninitialized register
    %vI_c7

}}}

The test in question is:

{{{

#include ""Cmm.h""

testLiteralBranch (W_ dst, W_ src)
{
  if (1) {
    prim %memcpy(dst, src, 1024, 4);
  } else {
    prim %memcpy(dst, src, 512, 8);
  }
  return ();
}

}}}

If you comment out the branch conditionals, the test passes, so clearly something fishy is going on here. The test also fails if you change the condition to ```if (1 == 1)```

I have absolutely no idea how this did not trip the profiling-based build in StgStdThunks.cmm, like in the LLVM build c.f. #7571",thoughtpolice
4,4316,58,"mmitar@…, haskell.vivian.mcphail@…, dterei","Interactive ""do"" notation in GHCi",GHCi,7.0.3,7.6.2,,new,low,2012-09-12T04:12:30-0700,"Enable GHCi to run commands under StateT monad based on IO or maybe even any other monad based on IO. So that you could for example exec a state and ""fall"" into this monad.

This could be generalized by supporting interactive ""do"" notation. Currently doing something like:

{{{
(flip execStateT) state $ do
}}}

raises ""Empty 'do' construct"" warning, but GHCi could go into interactive mode where it would be possible to write one command after another and it would execute them.",mitar
3,7460,56,"johan.tibell@…, daniel.is.fischer@…",Double literals generated bad core,Compiler,7.4.2,7.8.1,tibbe,new,normal,2013-04-12T13:36:22-0700,"The following code results in core containing expression like `doubleFromInteger (wordToInteger sc_s2pw)`:

{{{
{-# LANGUAGE CPP, BangPatterns #-}
module Main (main) where

#define VDIM 100
#define VNUM 100000

import Data.Array.Base
import Data.Array.ST
import Data.Array.Unboxed
import Control.Monad.ST
import GHC.Word
import Control.Monad
import Data.Bits

prng :: Word -> Word
prng w = w'
  where
    !w1 = w `xor` (w `shiftL` 13)
    !w2 = w1 `xor` (w1 `shiftR` 7)
    !w' = w2 `xor` (w2 `shiftL` 17)

type Vec s = STUArray s Int Double

kahan :: Vec s -> Vec s -> ST s ()
kahan s c = do
    let inner w j
            | j < VDIM  = do
                !cj <- unsafeRead c j
                !sj <- unsafeRead s j
                let !y = fromIntegral w - cj
                    !t = sj + y
                    !w' = prng w
                unsafeWrite c j ((t-sj)-y)
                unsafeWrite s j t
                inner w' (j+1)
            | otherwise = return ()
        outer i | i < VNUM = inner i 0 >> outer (i + 1)
                | otherwise = return ()
    outer 0

calc :: ST s (Vec s)
calc = do
    s <- newArray (0,VDIM-1) 0
    c <- newArray (0,VDIM-1) 0
    kahan s c
    return s

main :: IO ()
main = print . elems $ runSTUArray calc
}}}",tibbe
3,149,56,"michal.terepeta@…, hackage.haskell.org@…",missed CSE opportunity,Compiler,5.04.2,_|_,,new,normal,2013-05-02T08:49:01-0700,"Don't know if this is a bug, but it was at least
_surprising_ to find that

{{{
playerMostOccur [a] = a
playerMostOccur (x:xs)
 | numOccur x (x:xs) > numOccur (playerMostOccur xs) xs = x
 | otherwise = playerMostOccur xs
}}}

was exponentially slower when compiled with ghc-5.04.2
-O than:

{{{
playerMostOccur [a] = a
playerMostOccur (x:xs)
 | numOccur x (x:xs) > numOccur pmo xs = x
 | otherwise = pmo
 where pmo = playerMostOccur xs
}}}

Although the student responsible for the code couldn't
spot the
obvious optimisation, I was expecting that GHC's
optimiser would. :)
If it's not a bug, could you explain it to me?

-Greg(gregm.at.cs.uwa.edu.au)
",nobody
3,7942,54,"jdulaney@…, juhp@…",aarch64 support in ghc,Compiler,7.6.3,,,new,normal,2013-06-08T03:11:58-0700,"Hello.

Please, introduce the aarch64 support in ghc. The latest LLVM seems to support the aarch64 already.

Thanks in advance.

Regards,
Jaromir.",jcapik
2,5763,53,"dimitris@…, hackage.haskell.org@…",Confusing error message,Compiler,7.2.2,7.6.2,simonpj,new,high,2013-03-25T19:10:20-0700,"For test `indexed-types/should_fail/T4272` we get this type error
{{{
T4272.hs:11:16:
    Occurs check: cannot construct the infinite type:
      x0 = TermFamily x0 x0
    Expected type: TermFamily x0 x0
      Actual type: TermFamily a a
    In the first argument of `prune', namely `t'
    In the expression: prune t (terms (undefined :: TermFamily a a))
    In an equation for `laws':
        laws t = prune t (terms (undefined :: TermFamily a a))
}}}
It's not at all obvious why unifying `(TermFamily x0 x0)` with `(TermFamily a a)` should yield an occurs check. Especially as `TermFamily` is a type function with arity 1, and `x0` is a unification variable.  So the natural way to solve this constraint would be to unify `x0` with `a`, and then the constraint is satisfied.

What goes wrong is that there is ''another'' insolube constraint (which is also reported):
{{{
T4272.hs:11:19:
    Could not deduce (a ~ TermFamily x0 x0)
    from the context (TermLike a)
      bound by the type signature for
                 laws :: TermLike a => TermFamily a a -> b
      at T4272.hs:11:1-54
      `a' is a rigid type variable bound by
          the type signature for laws :: TermLike a => TermFamily a a -> b
          at T4272.hs:11:1
    In the return type of a call of `terms'
    In the second argument of `prune', namely
      `(terms (undefined :: TermFamily a a))'
    In the expression: prune t (terms (undefined :: TermFamily a a))
}}}
The constraint solver finds this latter constraint, can't solve it, ''but still uses it to simplify the first one'', by substituting `(TermFamily x0 x0)` for `a`; and that is what gives the occurs check error.

I don't think that we should use ''insoluble'' constraints to rewrite unsolved constraints.  But it's delicate, so I am not trying to fiddle right now. Hence making this ticket.

(Incidentally, it's not a regression; it's been like this forever.)
",simonpj
2,6166,53,"pho@…, dima@…, bgamari@…",Performance regression in mwc-random since 7.0.x,Compiler,7.4.2,7.6.2,,new,high,2012-09-12T04:11:55-0700,"I've had a report that the performance of the mwc-random package has regressed seriously after upgrading from GHC 7.0 to 7.4. It turns out that 7.2 also has the regression.

Here's a sample program.

{{{
import qualified Data.Vector.Unboxed as U

import qualified System.Random.MWC as R
import System.Random.MWC.Distributions (standard)

count = 1000 * 1000

fast gen = standard gen

slow gen = standard gen >>= return

-- Edit this to choose fast or slow.
which gen = slow gen

main = do
  gen <- R.create
  v <- U.replicateM count (which gen)
  print (U.last v)
}}} 

With GHC 7.0.3 -O2, this runs in 0.294 sec, regardless of whether `fast` or `slow` is used.

Under 7.4, `fast` runs in 0.062 sec (a nice speedup!), but `slow` now takes 9.2 sec (yikes!).

Roman suggested compiling the `slow` version with `-fno-state-hack`, which brings performance back up to 0.062 sec.",bos
2,7266,53,"daniel@…, hackage.haskell.org@…",Allow fractional-looking integer literals,Compiler,7.6.1,7.8.1,,new,high,2013-03-25T18:20:00-0700,"Haskell 2010 (2.5, 6.4.1) specifies that there are integer literals and floating literals, which are of types `(Num a) => a` and `(Fractional a) => a` respectively. This is mostly reasonable, because a `Rational` in general can't be converted to an arbitrary `Num` instance.

However, there are many specific cases where specifying an integer with compact ""floating literal"" syntax is reasonable (e.g. `1.2e6` instead of `1200000`). It's possible to do that for any floating literal constant which also happens to be an integer.

Several people have asked for that behavior. Attached is a patch for a proposed extension, `NumDecimals`, that implements it.

Note on #2245: The current fix won't work on converted floating literals, because it involves a special case for `FractionalLit` (the right thing to do is probably to generalize that solution, but doing that properly might be complicated). So with the extension enabled, `1e400` would be pretty-printed as an integer (just like 0400 is pretty-printed). Unlike the example in #2245, though, no information is lost -- floating literals would just be printed in integer form.",shachaf
3,7395,53,"hvr@…, v.dijk.bas@…, pho@…",DefaultSignatures conflict with default implementations,Compiler,7.6.1,7.8.1,,new,normal,2013-04-12T11:13:53-0700,"Default signatures cannot be used with default implementations.

This is quite annoying for the hashable package, as we'd like to provide both options to the user.

See the attached test case.",cgaebel
3,3024,53,"SamB, anton.nik@…, claudiusmaximus@…",Rewrite hp2ps in Haskell,Profiling,6.10.1,_|_,,new,normal,2012-10-21T08:52:46-0700,"Right now, hp2ps is written in rather difficult to modify C, and is quite inflexible. We should rewrite it in Haskell and make it, among other things, more tolerant to incomplete records.",SamB
4,4896,53,"mmitar@…, jpm@…, andres@…",Deriving Data does not work for attached code,Compiler,7.1,7.6.2,,new,low,2012-09-12T04:13:23-0700,"I get the following error when I try to derive `Data` for the attached code:

{{{
Main.hs:17:66:
    Couldn't match expected type `Bar (D a b)'
                with actual type `t' a1 b1'
    Expected type: Maybe (c (Bar (D a b)))
      Actual type: Maybe (c (t' a1 b1))
    In the expression: gcast2 f
    In an equation for `dataCast2': dataCast2 f = gcast2 f
}}}
",mitar
4,4114,53,"gwern0@…, merehap@…, tafryn@…",Add a flag to remove/delete intermediate files generated by GHC,Compiler,6.10.4,7.6.2,,new,low,2013-01-27T09:43:51-0800,"See for example http://stackoverflow.com/questions/1411089/how-to-stop-ghc-from-generating-intermediate-files or
http://www.haskell.org/pipermail/xmonad/2010-May/010180.html / 

Currently GHC generates *.o and *.hi files for executables, possibly quite a few. They take up space, filenames, and interfere with tab-completion.

(And they may be worse than that. I occasionally see users in #xmonad who seem to have subtle compilation issues after upgrades linked to stale .hi and .o files.)

There doesn't seem to be any good way to remove the intermediates for a program like Xmonad. They can't be redirected to /dev/null, it's a potential security problem to redirect them to /tmp, and removing them manually is difficult (Xmonad could hardwire in removeFiles of 'xmonad.o' and 'xmonad.hi', but what about the arbitrary user modules in ~/.xmonad/lib? Now one needs to start working with globs or utilities like 'find'...).

Of course, GHC knows precisely what's being generated, and could easily remove them. So another flag in the line of -fforce-recompilation seems warranted; perhaps -fforce-no-intermediates?",guest
5,3571,53,"batterseapower@…, michal.terepeta@…",Bizzarely bloated binaries,Compiler,6.10.4,7.6.2,,new,lowest,2012-09-12T04:14:12-0700,"Compiling a trivial test program:

{{{
module Main where

main = print ""Hello World""
}}}

Using GHC 6.10.4 produces a VERY suspicious PE file. (NB: this applies to DLL as well as EXE output).

The two problems that I have observed are:

 1) The PE always contains a .stab and .stabstr section totalling 0x2A00 of debug data. Looking at the contents of stabstr, this appears to originate from a libffi object file. Perhaps we could disable stabs when building libffi to remove this bloat from output binaries.

 2) The PE contains *A LOT* of trailing junk. My hello world program is 691K, and the PE contains 0x4FAFC = 318K of data which doesn't live in any section! Trimming this data appears to have no effect on the correctness of the program! The amount of junk grows proportionally to the amount of real code and data - I have observed e.g. 18Mb DLLs of which 9Mb are trailing junk.

To repeat: we could potentially *halve* GHC binary sizes by fixing this linker behaviour.

I'm not sure where exactly the fault lies - whether it is a GHC problem or some bug in Ld.

To test trimming your executables and DLLs, you can use this utility I whipped up. Usage is ""trimpe <file1> ... <fileN>"". It will trim useless data from the end of the files in place:

{{{
{-# LANGUAGE ScopedTypeVariables #-}
module Main (main) where

import Control.Monad

import Data.Binary
import Data.Binary.Get

import qualified Data.ByteString.Lazy as ByteString
import Data.Word

import System.Environment

import Debug.Trace


assertM :: Monad m => Bool -> m ()
assertM True  = return ()
assertM False = fail ""assertM""

newtype PEImageLength = PEImageLength Word32

-- http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
instance Binary PEImageLength where
    get = do
        -- Skip the MS DOS stub
        skip 0x3c
        pe_sig_offset <- getWord32le
        -- Skip to the PE signature
        skip (fromIntegral pe_sig_offset - (0x4 + 0x3c))
        -- Read the PE signature itself
        -- NB: this will always be the string ""PE\0\0""
        _sig <- getWord32le
        assertM (_sig == 0x00004550)
        -- Read COFF file header
        _machine <- getWord16le
        _no_of_sects <- getWord16le
        _time_date_stamp <- getWord32le
        _ptr_to_sym_tab <- getWord32le
        _no_of_syms <- getWord32le
        _size_of_opt_header <- getWord16le
        assertM (_size_of_opt_header /= 0)
        _characteristics <- getWord16le
        -- Read the ""optional"" header
        magic <- getWord16le
        let pe32plus = magic == 0x20B
        _maj_link_ver :: Word8 <- get
        _min_link_ver :: Word8 <- get
        _size_of_code <- getWord32le
        _size_of_init_data <- getWord32le
        _size_of_uninit_data <- getWord32le
        _addr_of_entry_point <- getWord32le
        _base_of_code <- getWord32le
        when (not pe32plus) $ do _base_of_data <- getWord32le; return ()
        -- Read the optional header Windows fields
        if pe32plus
         then do _image_base <- getWord64le; return ()
         else do _image_base <- getWord32le; return ()
        _sect_alignment <- getWord32le
        _file_alignment <- getWord32le
        _maj_os_version <- getWord16le
        _min_os_version <- getWord16le
        _maj_image_version <- getWord16le
        _min_image_version <- getWord16le
        _maj_subsys_version <- getWord16le
        _min_subsys_version <- getWord16le
        _win32_version <- getWord32le
        size_of_image <- getWord32le
        -- There is more stuff later, but I simply don't care about it
        -- NB: we could trim a little more agressively if we interpreted
        -- the sections as well...
        return $ PEImageLength size_of_image
        
    put = error ""Binary PEImageLength: put""


main :: IO ()
main = do
    files <- getArgs
    forM_ files trimPEToImageSize

trimPEToImageSize :: FilePath -> IO ()
trimPEToImageSize file = do
    putStrLn $ file
    pe_contents <- ByteString.readFile file
    let PEImageLength image_size = decode pe_contents
    
    -- Force the file to close so that the write may succeed
    (ByteString.last pe_contents) `seq` return ()
    
    when (ByteString.length pe_contents > fromIntegral image_size) $ do
        putStrLn $ ""* Trimming to image size ("" ++ show image_size ++ "")""
        let pe_contents' = ByteString.take (fromIntegral image_size) pe_contents
        ByteString.writeFile file pe_contents'
}}}",guest
2,7833,52,"ggreif@…, kazu@…, pho@…",installed GHC refers to libffi in the build directory,Build System,7.6.2,7.8.1,igloo,new,high,2013-04-16T18:27:15-0700,"In #7806, Kazu reported that on OS X:

After ""make install"", the installed GHC refers to libffi in the build directory.
{{{
% otool -L ghc | grep libffi

    /Users/kazu/work/ghc/libffi/build/inst/lib/libffi.6.dylib (compatibility version 7.0.0, current version 7.0.0)
}}}
So, after I did ""make maintainer-clean"", the installed GHC could not find a libffi.
",igloo
3,5556,52,"AntoineLatter, v.dijk.bas@…, as@…",Support pin-changing on ByteArray#s,Compiler,7.2.1,7.6.2,,new,normal,2012-09-12T04:12:05-0700,"I'm mostly posting this here as a chance for discussion for this feature, as I've wanted it a few times before and because Roman Leshchinskiy mentioned it on reddit and reminded me.

<quoting>

IIRC, the basic idea was to have an operation like:
{{{
pin# :: ByteArray# -> ByteArray#
}}}
Then you could say:
{{{
let y = pin# x
}}}
and y would have the same contents as x but be pinned. Whether it is the same memory block as x would be implementation-dependent but with GHC, it would be. When GHC would garbage collect y, it would unpin x (if x is still alive). You would also have unpin# so if you said:
{{{
let z = unpin# y
}}}
then z will become unpinned when y is garbage collected.

</quoting>

I mostly care because it's unfortunate to have to decide up front whether you want to suffer from memory fragmentation or to support foreign bindings. This could for example let us break the distinction between Data.Vector.Unboxed and Data.Vector.Storable. From a higher level, you might have a `withPinned` function that would temporarily pin (without copying) an array while you make foreign calls with it (even across multiple foreign calls), and then would unpin it when you're done.

I'm not sure what this would entail on the actual GC/runtime side of things, but I figured it'd be worth discussing.",pumpkin
3,6070,52,"stefan@…, carter.schonwald@…",Fun with the demand analyser,Compiler,7.4.1,7.8.1,simonpj,new,normal,2013-01-16T15:23:30-0800,"Max writes: I've been trying to speed up the supercompiler, and in the process
I've noticed some infelicities in the demand analyser that might be
worth looking at.

== Infelicity 1: analysis does not take into account extra unboxing done by the CPR transformation ==
An example is:
{{{
e :: (Int, Int) -> Int -> (Int, Int)
e x y = x `seq` if y > 10
         then x
         else e x (y + 1)
}}}
Because x is seqed, the occurrence in the ""then"" branch gets the CPR
property so e has the CPR property overall. However, the overall
demand on x is S(AA), i.e. the demand analyser believes the x box is
used -- if the box were unused it would get the demand U(LL). So the
overall demand type is S(AA)U(L)m, and the worker looks like:
{{{
Rec {
CPR2.$we [Occ=LoopBreaker]
  :: (GHC.Types.Int, GHC.Types.Int)
     -> GHC.Prim.Int# -> (# GHC.Types.Int, GHC.Types.Int #)
[GblId,
 Arity=2,
 Caf=NoCafRefs,
 Str=DmdType S(AA)L,
 Unf=OtherCon []]
CPR2.$we =
  \ (w_srv :: (GHC.Types.Int, GHC.Types.Int))
    (ww_srt :: GHC.Prim.Int#) ->
    case GHC.Prim.># ww_srt 10 of _ {
      GHC.Types.False ->
        case GHC.Prim.+# ww_srt 1 of sat_ssS { __DEFAULT ->
        CPR2.$we w_srv sat_ssS
        };
      GHC.Types.True ->
        case w_srv of _ { (ww2_srA, ww3_srB) -> (# ww2_srA, ww3_srB #) }
    }
end Rec }
}}}
But if we demand-analysed $we then GHC would say that it had the
demand type U(LL)L and unbox the pair argument! It seems silly that
the demand analyser outputs code that can be improved further by just
running demand analysis again.

Somewhere where this really bit me in practice is in:
{{{
d :: M.Map Int Int -> (Int, Int)
d m = M.foldrWithKey' (\k v (a, b) -> if k + v > 2 then (a, b) else
(b, a)) (0, 1) m
}}}
Which generates this inner loop:
{{{
Rec {
CPR2.$wgo2 [Occ=LoopBreaker]
  :: (GHC.Types.Int, GHC.Types.Int)
     -> Data.Map.Base.Map GHC.Types.Int GHC.Types.Int
     -> (# GHC.Types.Int, GHC.Types.Int #)
[GblId,
 Arity=2,
 Caf=NoCafRefs,
 Str=DmdType S(AA)S,
 Unf=OtherCon []]
CPR2.$wgo2 =
  \ (w_srS :: (GHC.Types.Int, GHC.Types.Int))
    (w1_srQ :: Data.Map.Base.Map GHC.Types.Int GHC.Types.Int) ->
    case w1_srQ of _ {
      Data.Map.Base.Tip ->
        case w_srS of _ { (ww1_srW, ww2_srX) -> (# ww1_srW, ww2_srX #) };
      Data.Map.Base.Bin rb_st1 kx_ss3 x_ssa l_ssk r_ss6 ->
        case kx_ss3 of _ { GHC.Types.I# x1_ssd ->
        case CPR2.$wgo2 w_srS r_ss6 of _ { (# ww1_ssi, ww2_ssh #) ->
        case x_ssa of _ { GHC.Types.I# y_sse ->
        case GHC.Prim.+# x1_ssd y_sse of sat_st0 { __DEFAULT ->
        case GHC.Prim.># sat_st0 2 of _ {
          GHC.Types.False ->
            let {
              sat_ssZ :: (GHC.Types.Int, GHC.Types.Int)
              [LclId]
              sat_ssZ = (ww2_ssh, ww1_ssi) } in
            CPR2.$wgo2 sat_ssZ l_ssk;
          GHC.Types.True ->
            let {
              sat_st6 :: (GHC.Types.Int, GHC.Types.Int)
              [LclId]
              sat_st6 = (ww1_ssi, ww2_ssh) } in
            CPR2.$wgo2 sat_st6 l_ssk
        }
        }
        }
        }
        }
    }
end Rec }
}}}
We can save a number of allocations proportional to the size of the
Map if the demand analyser didn't have this problem.

I hacked up the analyser to ""fix"" this by changing the lines at line
473 onward to read:
{{{
    if isTopLevel top_lvl
     then fn_ty	-- Don't record top level things
     else case dmd of
            Box (Eval (Poly Abs)) | DmdType _ _ res <- fn_ty,
returnsCPR res -> addVarDmd fn_ty var (Eval (Poly lazyDmd))
            _
      -> addVarDmd fn_ty var dmd
}}}
So if we demand a CPRish variable (such as bound by a case scrutinee
or a U(LL)-demanded lambda-binder) in the evalDmd then I throw away
the Box part of the evalDmd on the basis that after CPRing we won't
demand the box at all.

I doubt this hack is the right solution (and I haven't tried it to see
how it affects the libraries) but perhaps it gives you some ideas.


== Infelicity 2: a case where demand summarisation hurts us ==

I found practical examples where summarising the demand transfomer of
a function as a single strictness signature hurt us. The examples were
code like:
{{{
h :: (Int, Int) -> Int -> (Int, Int)
h x y = if y > 10
         then x
         else h (case h x 0 of (y1, y2) -> (y2, y1)) (y + 1)
}}}
If, at the innermost use of h, we re-analyse h in the demand
C(C(U(LL))) rather than just unleashing the vanilla DmdSig computed
from the demand C(C(S)) then we can unbox the pair argument. Currently
GHC just gives h the DmdType SU(L) which doesn't eliminate the
allocation of the pair at all.

This situation occurs in practice with code like:
{{{
c :: M.Map Int Int -> (Int, Int)
c m = M.foldrWithKey (\k v (a, b) -> if k + v > 2 then (a, b) else (b,
a)) (0, 1) m
}}}
The difference from my earlier example d is that I'm using the version
of `foldrWithKey` that doesn't call `seq`. Current GHC generates this
inner loop:
{{{
Rec {
CPR2.c_go2 [Occ=LoopBreaker]
  :: (GHC.Types.Int, GHC.Types.Int)
     -> Data.Map.Base.Map GHC.Types.Int GHC.Types.Int
     -> (GHC.Types.Int, GHC.Types.Int)
[GblId,
 Arity=2,
 Caf=NoCafRefs,
 Str=DmdType U(L*)S,
 Unf=OtherCon []]
CPR2.c_go2 =
  \ (z_spW :: (GHC.Types.Int, GHC.Types.Int))
    (ds_spU :: Data.Map.Base.Map GHC.Types.Int GHC.Types.Int) ->
    case ds_spU of _ {
      Data.Map.Base.Tip -> z_spW;
      Data.Map.Base.Bin rb_sqq kx_sq2 x_sq9 l_sqj r_sq5 ->
        case kx_sq2 of _ { GHC.Types.I# x1_sqc ->
        case CPR2.c_go2 z_spW r_sq5 of wild2_sqk { (a_sqh, b_sqg) ->
        case x_sq9 of _ { GHC.Types.I# y_sqd ->
        case GHC.Prim.+# x1_sqc y_sqd of sat_sqp { __DEFAULT ->
        case GHC.Prim.># sat_sqp 2 of _ {
          GHC.Types.False ->
            let {
              sat_sqo :: (GHC.Types.Int, GHC.Types.Int)
              [LclId]
              sat_sqo = (b_sqg, a_sqh) } in
            CPR2.c_go2 sat_sqo l_sqj;
          GHC.Types.True -> CPR2.c_go2 wild2_sqk l_sqj
        }
        }
        }
        }
        }
    }
end Rec }
}}}
I implemented this but the overhead of reanalysing a function at each
occurrence site is prohibitive (with my changes paraffins took 2.5s to
compile instead of 0.3s). It does fix the problem though.

A scheme like in ""stricterness more relevant"" but with let-binding
that is polymorphic in the use-site demand might be able to detect the
extra strictness here. I think Stefan Holdermanns has a paper
describing such a system. But this is anyway much harder to fix than
my first infelicity.
",simonpj
3,7206,52,"mail@…, carter.schonwald@…",Implement cheap build,Compiler,7.4.2,_|_,simonpj,new,normal,2013-02-13T00:56:12-0800,"We sometimes see stuff like this:
{{{
f n ps = let ys = [1..x]
         in map (\zs. ys ++ zs) ps
}}}
You might think the `(++)` would fuse with the `[1..x]`, via foldr/build fusion, but it doesn't.  Why not?  Because it would be WRONG to do so in this case:
{{{
f ns ps = let ys = map expensive ns
          in map (\zs. ys ++ zs) ps
}}}
If we fused the `(++)` with the `map` we might call `expensive` once for each element of `ps`.

This is fairly easy to fix. The point is that `[1..x]` is cheap; we'd prefer to fuse it even if doing so involves computing 1, 1+1, 2+1, etc multiple times.  Suppose we express this fact thusly:
{{{
enumFromTo lo hi = cheapBuild (\cn. ....lo...hi...)
map f xs = build (\cn. ...f...xs...)
}}}
Now we want the `foldr/cheapBuild` rule to fire even if that would involve duplicating the call to `cheapBuild`.  And we already have a way to do that: we make `cheapBuild` into a `CONLIKE` function.

Happily it's almost all simply a change to the libraries, not the compiler itself.

I just need to execute on this, but I keep failing to get round to it.  Below is the beginning. One missing piece is that I need to replace the hack for `build` in the occurrence analyser, so that it works for `cheapBuild` too.  (At least until we have Ilya's cardinality analyser.)

Simon

{{{
diff --git a/GHC/Base.lhs b/GHC/Base.lhs
index 6a36eb5..b78edf5 100644
--- a/GHC/Base.lhs
+++ b/GHC/Base.lhs
@@ -304,6 +304,12 @@ build   :: forall a. (forall b. (a -> b -> b) -> b -> b) -> [a]

 build g = g (:) []

+cheapBuild   :: forall a. (forall b. (a -> b -> b) -> b -> b) -> [a]
+{-# INLINE CONLIKE [1] cheapBuild #-}
+-- cheapBuild is just like build, except that it is CONLIKE
+-- See Note [cheapBuild]
+cheapBuild g = g (:) []
+
-- | A list producer that can be fused with 'foldr'.
-- This function is merely
--
@@ -320,6 +326,8 @@ augment g xs = g (:) xs
{-# RULES
""fold/build""    forall k z (g::forall b. (a->b->b) -> b -> b) . 
                 foldr k z (build g) = g k z
+""fold/cheapBuild""    forall k z (g::forall b. (a->b->b) -> b -> b) . 
+                     foldr k z (cheapBuild g) = g k z

 ""foldr/augment"" forall k z xs (g::forall b. (a->b->b) -> b -> b) . 
                 foldr k z (augment g xs) = g k (foldr k z xs)
@@ -343,6 +351,12 @@ augment g xs = g (:) xs
""augment/build"" forall (g::forall b. (a->b->b) -> b -> b)
                        (h::forall b. (a->b->b) -> b -> b) .
                        augment g (build h) = build (\c n -> g c (h c n))
+
+""augment/cheapBuild"" forall (g::forall b. (a->b->b) -> b -> b)
+                       (h::forall b. (a->b->b) -> b -> b) .
+                       augment g (cheapBuild h) = build (\c n -> g c (h c n))
+   -- 'augment' doesn't necessarily have a cheap argument, so we revert to 'build'
+
""augment/nil""   forall (g::forall b. (a->b->b) -> b -> b) .
                         augment g [] = build g
  #-}
@@ -351,6 +365,20 @@ augment g xs = g (:) xs
--      augment g (augment h t) = augment (\cn -> g c (h c n)) t
\end{code}

+Note [cheapBuild]
+~~~~~~~~~~~~~~~~~
+cheapBuild is just like build, except that it is CONLIKE
+
+It is used in situations where fusion is more imortant than sharing,
+ie in situation where its argument function 'g' in (cheapBuild g) is
+cheap.
+
+Main example: enumerations of one kind or another:
+    f x = let xs = [x..] 
+              go = \y. ....go y'....(map (h y) xs)...
+          in ...
+Here we woud like to fuse the map with the [x..]
+

 ----------------------------------------------
--              map     
@@ -831,7 +859,7 @@ a `iShiftRL#` b | b >=# WORD_SIZE_IN_BITS# = 0#

 -- Rules for C strings (the functions themselves are now in GHC.CString)
{-# RULES
-""unpack""       [~1] forall a   . unpackCString# a             = build (unpackFoldrCString# a)
+""unpack""       [~1] forall a   . unpackCString# a             = cheapBuild (unpackFoldrCString# a)
""unpack-list""  [1]  forall a   . unpackFoldrCString# a (:) [] = unpackCString# a
""unpack-append""     forall a n . unpackFoldrCString# a (:) n  = unpackAppendCString# a n

diff --git a/GHC/Enum.lhs b/GHC/Enum.lhs
index cea3ced..561a995 100644
--- a/GHC/Enum.lhs
+++ b/GHC/Enum.lhs
@@ -376,9 +376,9 @@ instance  Enum Char  where
     enumFromThenTo (C# x1) (C# x2) (C# y) = efdtChar (ord# x1) (ord# x2) (ord# y)

 {-# RULES
-""eftChar""       [~1] forall x y.        eftChar x y       = build (\c n -> eftCharFB c n x y)
-""efdChar""       [~1] forall x1 x2.      efdChar x1 x2     = build (\ c n -> efdCharFB c n x1 x2)
-""efdtChar""      [~1] forall x1 x2 l.    efdtChar x1 x2 l  = build (\ c n -> efdtCharFB c n x1 x2 l)
+""eftChar""       [~1] forall x y.        eftChar x y       = cheapBuild (\c n -> eftCharFB c n x y)
+""efdChar""       [~1] forall x1 x2.      efdChar x1 x2     = cheapBuild (\ c n -> efdCharFB c n x1 x2)
+""efdtChar""      [~1] forall x1 x2 l.    efdtChar x1 x2 l  = cheapBuild (\ c n -> efdtCharFB c n x1 x2 l)
""eftCharList""   [1]  eftCharFB  (:) [] = eftChar
""efdCharList""   [1]  efdCharFB  (:) [] = efdChar
""efdtCharList""  [1]  efdtCharFB (:) [] = efdtChar
@@ -510,7 +510,7 @@ instance  Enum Int  where
-- In particular, we have rules for deforestation

 {-# RULES
-""eftInt""        [~1] forall x y. eftInt x y = build (\ c n -> eftIntFB c n x y)
+""eftInt""        [~1] forall x y. eftInt x y = cheapBuild (\ c n -> eftIntFB c n x y)
""eftIntList""    [1] eftIntFB  (:) [] = eftInt
  #-}

@@ -539,7 +539,7 @@ eftIntFB c n x0 y | x0 ># y    = n

 {-# RULES
""efdtInt""       [~1] forall x1 x2 y.
-                     efdtInt x1 x2 y = build (\ c n -> efdtIntFB c n x1 x2 y)
+                     efdtInt x1 x2 y = cheapBuild (\ c n -> efdtIntFB c n x1 x2 y)
""efdtIntUpList"" [1]  efdtIntFB (:) [] = efdtInt
  #-}

@@ -646,8 +646,8 @@ instance  Enum Integer  where
     enumFromThenTo x y lim = enumDeltaToInteger x (y-x) lim

 {-# RULES
-""enumDeltaInteger""      [~1] forall x y.  enumDeltaInteger x y     = build (\c _ -> enumDeltaIntegerFB c x y)
-""efdtInteger""           [~1] forall x y l.enumDeltaToInteger x y l = build (\c n -> enumDeltaToIntegerFB c n x y l)
+""enumDeltaInteger""      [~1] forall x y.  enumDeltaInteger x y     = cheapBuild (\c _ -> enumDeltaIntegerFB c x y)
+""efdtInteger""           [~1] forall x y l.enumDeltaToInteger x y l = cheapBuild (\c n -> enumDeltaToIntegerFB c n x y l)
""enumDeltaInteger""      [1] enumDeltaIntegerFB   (:)    = enumDeltaInteger
""enumDeltaToInteger""    [1] enumDeltaToIntegerFB (:) [] = enumDeltaToInteger
  #-}
}}}",simonpj
3,4894,52,"dimitris@…, mikhail.vorozhtsov@…",Missing improvement for fun. deps.,Compiler (Type checker),7.1,_|_,,new,normal,2011-05-01T02:51:29-0700,"The problem is illustrated by the following example:

{{{
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-}

class F a b | a -> b

f :: (F a b, F a c) => a -> b -> c
f _ = id

Results in the following error:

    Could not deduce (b ~ c)
    from the context (F a b, F a c)
      bound by the type signature for f :: (F a b, F a c) => a -> b -> c
      at bug.hs:6:1-8
      `b' is a rigid type variable bound by
          the type signature for f :: (F a b, F a c) => a -> b -> c
          at bug.hs:6:1
      `c' is a rigid type variable bound by
          the type signature for f :: (F a b, F a c) => a -> b -> c
          at bug.hs:6:1
    Expected type: b -> c
      Actual type: b -> b
    In the expression: id
    In an equation for `f': f _ = id
}}}

The issue seems to be related to Note [When improvement happens] in module TcInteract.  It states that two ""givens"" do not interact for the purposes of improvement.

As far as I understand, the correct behavior should be to generate a new given equality, justified by the functional dependency on the class.

This is also related to bug #1241: in order to justify an improvement by functional dependency, we have to check that all instances are consistent with the dependency.  Otherwise, the above function would turn into an ""unsafe cast"" function.
",diatchki
1,5757,51,"mail@…, dterei, eir@…",zero unexpected failures on all tier 1 platforms,Test Suite,7.2.1,7.6.2,,new,highest,2013-01-06T03:10:04-0800,"We're often sloppy about this, so I'm making a ticket to ensure we can tag a testsuite that has zero unexpected failures on all tier 1 platforms at release time.

That may mean filing more tickets and marking some tests as expected failures.

I'll take {x86_64,x86}/Linux.
",simonmar
2,7679,51,"tibbe, benl, pho@…, shelarcy@…",Regression in -fregs-graph performance,Compiler (NCG),7.6.2,7.8.1,,new,high,2013-02-12T19:11:32-0800,"Likely due to a bad interaction with the new code generator, see #7192.

`-fregs-graph` used to be on by default with `-O2`, but is currently off due to this issue.

Results courtesy of @tibbe:

{{{
HEAD vs HEAD with -fregs-graph:

--------------------------------------------------------------------------------
        Program           Size    Allocs   Runtime   Elapsed  TotalMem
--------------------------------------------------------------------------------
           anna          +0.1%     +0.0%      0.08      0.08     +0.0%
           ansi          +0.0%     +0.0%      0.00      0.00     +0.0%
           atom          +0.0%     +0.0%     +0.0%     -0.8%     +0.0%
         awards          -0.0%     +0.0%      0.00      0.00     +0.0%
         banner          -0.0%     +0.0%      0.00      0.00     +0.0%
     bernouilli          +0.0%     +0.0%      0.12      0.12     +0.0%
   binary-trees          +0.0%     +0.0%     +0.0%     +0.0%     +0.0%
          boyer          -0.0%     +0.0%      0.04      0.04     +0.0%
         boyer2          -0.0%     +0.0%      0.01      0.01     +0.0%
           bspt          -0.0%     +0.0%      0.02      0.02     +0.0%
      cacheprof          +0.0%     +0.0%     -3.1%     -3.1%     +0.0%
       calendar          -0.0%     +0.0%      0.00      0.00     +0.0%
       cichelli          +0.0%     +0.0%      0.05      0.05     +3.0%
        circsim          +0.0%     +0.0%     -0.3%     -0.3%     +0.0%
       clausify          -0.0%     +0.0%      0.03      0.03     +0.0%
  comp_lab_zift          -0.0%     +0.0%      0.14      0.14     +0.0%
       compress          +0.0%     +0.0%      0.11      0.11     +0.0%
      compress2          +0.0%     +0.0%      0.14      0.14     +0.0%
    constraints          +0.0%     +0.0%     -1.4%     -1.4%     +0.0%
   cryptarithm1          +0.0%     +0.0%     +1.6%     +1.0%     +0.0%
   cryptarithm2          +0.0%     +0.0%      0.01      0.01     +0.0%
            cse          +0.0%     +0.0%      0.00      0.00     +0.0%
          eliza          -0.0%     +0.0%      0.00      0.00     +0.0%
          event          +0.0%     +0.0%      0.10      0.10     +0.0%
         exp3_8          +0.0%     +0.0%      0.14      0.14     +0.0%
         expert          +0.0%     +0.0%      0.00      0.00     +0.0%
 fannkuch-redux          +0.0%     +0.0%    +10.6%    +10.4%     +0.0%
          fasta          -0.0%     +0.0%     -0.6%     -0.6%     +0.0%
            fem          +0.0%     +0.0%      0.03      0.03     +0.0%
            fft          -0.0%     +0.0%      0.03      0.03     +0.0%
           fft2          +0.0%     +0.0%      0.04      0.04     +0.0%
       fibheaps          -0.0%     +0.0%      0.03      0.03     +0.0%
           fish          +0.0%     +0.0%      0.01      0.01     +0.0%
          fluid          +0.0%     +0.0%      0.01      0.01     +0.0%
         fulsom          +0.1%     +0.0%     -5.9%     -5.9%     -5.3%
         gamteb          +0.0%     +0.0%      0.04      0.04     +0.0%
            gcd          +0.0%     +0.0%      0.03      0.03     +0.0%
    gen_regexps          +0.0%     +0.0%      0.00      0.00     +0.0%
         genfft          +0.0%     +0.0%      0.03      0.03     +0.0%
             gg          +0.0%     +0.0%      0.02      0.02     +0.0%
           grep          +0.1%     +0.0%      0.00      0.00     +0.0%
         hidden          +0.0%     +0.0%     +3.4%     +2.7%     +0.0%
            hpg          +0.0%     +0.0%      0.10      0.10     +0.0%
            ida          -0.0%     +0.0%      0.06      0.06     +0.0%
          infer          +0.0%     +0.0%      0.05      0.05     +0.0%
        integer          -0.0%     +0.0%     +3.0%     +2.9%     +0.0%
      integrate          +0.0%     +0.0%      0.13      0.13     +0.0%
   k-nucleotide          +0.4%     +0.0%     +3.4%     +3.5%     +0.0%
          kahan          +0.0%     +0.0%      0.18      0.18     +0.0%
        knights          -0.1%     +0.0%      0.01      0.01     +0.0%
           lcss          +0.0%     +0.0%     +0.7%     +0.7%     +0.0%
           life          -0.0%     +0.0%      0.16      0.16     +0.0%
           lift          +0.0%     +0.0%      0.00      0.00     +0.0%
      listcompr          -0.0%     +0.0%      0.06      0.06     +0.0%
       listcopy          -0.0%     +0.0%      0.06      0.06     +0.0%
       maillist          -0.0%     +0.0%      0.04      0.04    -11.2%
         mandel          +0.0%     +0.0%      0.05      0.05     +0.0%
        mandel2          -0.0%     +0.0%      0.00      0.00     +0.0%
        minimax          +0.0%     +0.0%      0.00      0.00     +0.0%
        mkhprog          +0.0%     +0.0%      0.00      0.00     +0.0%
     multiplier          -0.0%     +0.0%      0.08      0.08     +0.0%
         n-body          -0.0%     +0.0%    +28.2%    +28.2%     +0.0%
       nucleic2          +0.0%     +0.0%      0.05      0.05     +0.0%
           para          -0.1%     +0.0%     +1.0%     +1.0%     +0.0%
      paraffins          -0.0%     +0.0%      0.08      0.08     +0.0%
         parser          +0.0%     +0.0%      0.03      0.03     +0.0%
        parstof          -0.0%     +0.0%      0.00      0.00     +0.0%
            pic          -0.0%     +0.0%      0.00      0.00     +0.0%
       pidigits          -0.0%     +0.0%     -0.6%     +0.0%     +0.0%
          power          +0.0%     +0.0%     +1.9%     +1.9%     +0.0%
         pretty          +0.0%     +0.0%      0.00      0.00     +0.0%
         primes          -0.0%     +0.0%      0.05      0.05     +0.0%
      primetest          -0.0%     +0.0%      0.07      0.07     +0.0%
         prolog          +0.0%     +0.0%      0.00      0.00     +0.0%
         puzzle          -0.0%     +0.0%      0.10      0.10     +0.0%
         queens          +0.0%     +0.0%      0.02      0.02     +0.0%
        reptile          +0.0%     +0.0%      0.02      0.02     +0.0%
reverse-complem          -0.0%     +0.0%      0.08      0.08     +0.0%
        rewrite          +0.0%     +0.0%      0.02      0.02     +0.0%
           rfib          +0.0%     +0.0%      0.02      0.02     +0.0%
            rsa          +0.0%     +0.0%      0.03      0.03     +0.0%
            scc          -0.0%     +0.0%      0.00      0.00     +0.0%
          sched          -0.0%     +0.0%      0.02      0.02     +0.0%
            scs          -0.0%     +0.0%     -1.1%     -0.5%     +0.0%
         simple          -0.1%     +0.0%      0.16      0.16     +0.0%
          solid          -0.0%     +0.0%      0.10      0.10     +0.0%
        sorting          -0.0%     +0.0%      0.00      0.00     +0.0%
  spectral-norm          -0.0%     +0.0%     +0.0%     +0.0%     +0.0%
         sphere          +0.1%     +0.0%      0.03      0.03     +0.0%
         symalg          -0.0%     +0.0%      0.01      0.01     +0.0%
            tak          +0.0%     +0.0%      0.01      0.01     +0.0%
      transform          -0.0%     +0.0%     +0.0%     +0.0%     +0.0%
       treejoin          +0.0%     +0.0%      0.15      0.15     +0.0%
      typecheck          +0.0%     +0.0%      0.15      0.15     +0.0%
        veritas          +0.1%     +0.0%      0.00      0.00     +0.0%
           wang          +0.0%     +0.0%      0.08      0.08     +0.0%
      wave4main          +0.0%     +0.0%      0.19      0.19     +0.0%
   wheel-sieve1          -0.0%     +0.0%     -0.8%     -0.8%     +0.0%
   wheel-sieve2          -0.0%     +0.0%      0.13      0.13     +0.0%
           x2n1          -0.0%     +0.0%      0.01      0.01     +0.0%
--------------------------------------------------------------------------------
            Min          -0.1%     +0.0%     -5.9%     -5.9%    -11.2%
            Max          +0.4%     +0.0%    +28.2%    +28.2%     +3.0%
 Geometric Mean          +0.0%     -0.0%     +1.7%     +1.7%     -0.1%
}}}

",simonmar
4,3744,51,"daniel.is.fischer@…, michal.terepeta@…",Comparisons against minBound/maxBound not optimised,Compiler,6.13,7.6.2,,new,low,2012-09-12T04:12:20-0700,"{{{
foo :: Int -> Bool
foo n = n < minBound || n > maxBound
}}}

GHC retains both comparisons even though they are guaranteed to be False. This also happens for other integral types. The optimisation is fairly easy to implement for `Int` and `Word` (only requires some plumbing in !PrelRules) but it's not clear what to do about smaller integral types. For `Int64` and `Word64`, GHC doesn't even inline `minBound` and `maxBound`:

{{{
T.$wfoo :: GHC.Prim.Int64# -> GHC.Bool.Bool
T.$wfoo =
  \ (ww_ss5 :: GHC.Prim.Int64#) ->
    case GHC.Int.$fBoundedInt64_$cminBound
    of _ { GHC.Int.I64# y#_are ->
    case {__ccall hs_ltInt64 GHC.Prim.Int64#
                    -> GHC.Prim.Int64#
                    -> GHC.Prim.State# GHC.Prim.RealWorld
                    -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Prim.Int# #)}_arD
           ww_ss5 y#_are GHC.Prim.realWorld#
    of _ { (# _, ds3_arH #) ->
    case ds3_arH of _ {
      __DEFAULT -> GHC.Bool.True;
      0 ->
        case GHC.Int.$fBoundedInt64_$cmaxBound
        of _ { GHC.Int.I64# y#1_ar4 ->
        GHC.IntWord64.gtInt64# ww_ss5 y#1_ar4
        }
    }
    }
    }

T.foo :: GHC.Int.Int64 -> GHC.Bool.Bool
T.foo =
  \ (w_ss3 :: GHC.Int.Int64) ->
    case w_ss3 of _ { GHC.Int.I64# ww_ss5 -> T.$wfoo ww_ss5 }

}}}
",rl
4,4429,51,"haskell@…, andy.adamsmoran@…",Ability to specify the namespace in mkName,Template Haskell,6.12.3,7.6.2,reinerp,new,low,2013-02-07T17:54:54-0800,"Given

{{{
data Foo
data Bar = Foo
}}}

If we do {{{reify (mkName ""Foo"")}}} then we get the information about ""{{{Foo}}} the type"", and not about ""{{{Foo}}} the constructor"". 

(This is problematic, say, for a quasiquoter
{{{ 
[qq| ... Foo ... |] 
}}}

because the quasiquoter is forced to use {{{mkName ""Foo""}}} as the {{{Name}}} for reify -- the forms {{{'Foo}}} and {{{''Foo}}} are unavailable to it.)

I would like a way around this problem. It seems like it would be enough to communicate the namespace to {{{mkName}}}, so that the ambiguity no longer exists.",reinerp
3,7694,50,"carter.schonwald@…, jan.stolarek@…",LLVM: bootstrapping with LLVM 3.2 does not work,Compiler (LLVM),7.7,7.8.1,dterei,new,normal,2013-06-17T20:38:59-0700,"Building GHC itself using the LLVM back end no longer works with LLVM 3.2 (3.1 is fine). On Linux x86_64, the stage2 compiler fails for me. Unfortunately running the test suite with stage=1 did not produce any quality failures that would help us track down the problem. This does not appear to be related to the new codegen since using LLVM 3.1 does not cause a failure.",gmainland
3,670,50,"ndmitchell@…, chevalier@…",External Core is broken,External Core,6.8.2,_|_,tim,new,normal,2011-08-28T16:58:42-0700,"{{{
$ ghc -fext-core Main.hs
$ ghc -fglasgow-exts Main.hcr
ghc-6.5: panic! (the `impossible' happened, GHC version 6.5):
	tcIfaceGlobal (local): not found:
    Main.main{v rrl}
    []

Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
}}}

Main.hs consists of:
{{{ main = putStr ""Hello world!"" }}}

I'll fix this myself if I still have commit access; I just want to have a record of it.",KirstenChevalier
3,3583,50,"illissius@…, hackage.haskell.org@…",Default view patterns,Compiler,6.10.4,_|_,,new,normal,2013-03-25T19:16:10-0700,as useful for code like http://hpaste.org/fastcgi/hpaste.fcgi/view?id=10699#a10699 : Provide a unified left-hand interface for [] and Seq with the same syntax as current lists.,ksf
4,4938,50,"william.knop.nospam@…, anton.nik@…",Core2 CPU not detected correctly,Compiler,7.1,7.6.2,,new,low,2012-09-12T04:13:24-0700,"This is a HEAD build on a Core2 Duo (i386 & x86_64) MacBook Pro. 

Configure Command: `./configure --host=x86_64-apple-darwin --target=x86_64-apple-darwin`

Configure Summary:
{{{
Configure completed successfully.

   Building GHC version  : 7.1.20110131

   Build platform        : i386-apple-darwin
   Host platform         : x86_64-apple-darwin
   Target platform       : x86_64-apple-darwin

   Bootstrapping using   : /usr/bin/ghc
      which is version   : 6.12.3

   Using GCC             : /usr/bin/gcc
      which is version   : 4.2.1

   ld       : /usr/bin/ld
   Happy    : /usr/local/bin/happy (1.18.5)
   Alex     : /usr/local/bin/alex (2.3.3)
   Python   : /usr/bin/python
   Perl     : /usr/bin/perl
   dblatex  : /usr/local/bin/dblatex
   xsltproc : /usr/bin/xsltproc
   HsColour : /Users/wknop/.cabal/bin/HsColour

   Building DocBook HTML documentation : YES
   Building DocBook PS documentation   : YES
   Building DocBook PDF documentation  : YES
}}}

Build fails with:
{{{
compiler/stage2/build/LibFFI_hsc_make.c:1: error: CPU you selected does not support x86-64 instruction set
}}}

Workaround: Adding `-march=core2` to the `x86_64-apple-darwin` section of `aclocal.m4` convinces the compiler that the processor supports i386 and x86_64.
",altaic
4,5682,50,"jpm@…, eir@…, trevor@…",Properly parse kind operators (from promoted type operators),Compiler,7.3,7.6.2,dreixel,new,low,2013-04-22T17:48:41-0700,"{{{
% ghci -XPolyKinds -XTypeOperators
GHCi, version 7.3.20111204: 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> :k (:)

<interactive>:1:2: parse error on input `:'
Prelude> :k '(:)

<interactive>:1:3: parse error on input `:'
Prelude> :k (':)

<interactive>:1:3: parse error on input `:'
Prelude> :k (Int ': '[Bool])
(Int ': '[Bool]) :: [*]
}}}",lunaris
5,1012,50,"leuschner@…, ozgurakgun@…",ghc panic with mutually recursive modules and template haskell,Template Haskell,6.8.2,7.6.2,,new,lowest,2013-05-02T08:01:29-0700,"When compiling the files below using ghc --make Main.hs I get the following error:
{{{
[1 of 5] Compiling ModuleA[boot]    ( ModuleA.hs-boot, nothing )
[2 of 5] Compiling ModuleC          ( ModuleC.hs, ModuleC.o )
[3 of 5] Compiling ModuleB          ( ModuleB.hs, ModuleB.o )
Loading package base ... linking ... done.
Loading package template-haskell ... linking ... done.
ghc-6.6: panic! (the 'impossible' happened)
  (GHC version 6.6 for powerpc-apple-darwin):
        Maybe.fromJust: Nothing
}}}


ModuleA.hs:
{{{
module ModuleA where

import ModuleB
}}}

ModuleA.hs-boot:
{{{
module ModuleA where
}}}

ModuleB.hs:
{{{
{-# OPTIONS -fth #-}
module ModuleB where

import ModuleC

$(nothing)
}}}

ModuleC.hs:
{{{
module ModuleC where

import Language.Haskell.TH

import {-# SOURCE #-} ModuleA

nothing = return [] :: Q [Dec]
}}}

Main.hs:
{{{
module Main.hs

import ModuleA

main = return ()
}}}",guest
2,5859,49,"pho@…, hackage.haskell.org@…",unsafeInterleaveIO duplicates computation when evaluated by multiple threads,libraries/base,7.2.2,7.6.2,simonpj,new,high,2013-03-25T19:09:53-0700,"When the following code is compiled with -O1 or -O2, the interleaved computation (putStrLn ""eval"") is performed 1000 times, rather than once:

{{{
import Control.Concurrent
import Control.Exception (evaluate)
import Control.Monad
import System.IO.Unsafe

main :: IO ()
main = do
    x <- unsafeInterleaveIO $ putStrLn ""eval""
    replicateM_ 1000 $ forkIO $ evaluate x >> return ()
    threadDelay 1000000
}}}

Taking a look at the source to unsafeInterleaveIO:

{{{
{-# INLINE unsafeInterleaveIO #-}
unsafeInterleaveIO :: IO a -> IO a
unsafeInterleaveIO m = unsafeDupableInterleaveIO (noDuplicate >> m)

-- We believe that INLINE on unsafeInterleaveIO is safe, because the
-- state from this IO thread is passed explicitly to the interleaved
-- IO, so it cannot be floated out and shared.
}}}

It seems the comment about INLINE is not true.  If I define the following function:

{{{
interleave :: IO a -> IO a
interleave = unsafeInterleaveIO
{-# NOINLINE interleave #-}
}}}

and replace unsafeInterleaveIO with interleave, ""eval"" is printed only once.  If I change NOINLINE to INLINE, or if I remove the pragma altogether, ""eval"" is printed 1000 times.

I believe unsafeInterleaveIO should ''guarantee'' that computations are not repeated.  Otherwise, we end up with strangeness like this:

{{{
import Control.Applicative
import Control.Concurrent
import Control.Monad

main :: IO ()
main = do
    chan <- newChan :: IO (Chan Int)
    mapM_ (writeChan chan) [0..999]
    items <- take 10 <$> getChanContents chan
    replicateM_ 5 $ forkIO $ putStrLn $ ""items = "" ++ show items
    threadDelay 1000000
}}}

which prints:

{{{
items = [0,1,2,3,4,5,6,7,8,9]
items = [10,11,12,13,14,15,16,17,18,19]
items = [20,21,22,23,24,25,26,27,28,29]
items = [30,31,32,33,34,35,36,37,38,39]
items = [40,41,42,43,44,45,46,47,48,49]
}}}

For the time being, programs can work around this by using a NOINLINE wrapper:

{{{
getChanContents' :: Chan a -> IO [a]
getChanContents' = getChanContents
{-# NOINLINE getChanContents' #-}
}}}

I tested this on Linux 64-bit with GHC 7.2.2 and ghc-7.4.0.20120111, and on Windows 32-bit with GHC 7.0.3 and 7.2.2.  All of these platforms and versions exhibit the same behavior.  The bug goes away when the program is compiled with -O0, or when functions returning interleaved computations are marked NOINLINE (e.g. getChanContents').",joeyadams
3,4139,49,"eir@…, hackage.haskell.org@…",Spurious non-exhaustive pattern match warnings are given using GADTs,Compiler,7.4.1,7.0.1,,new,normal,2013-03-22T03:18:40-0700,"When using slightly complicated GADTs, GHC gives me erroneous non-exhaustive pattern match warnings.  I have attached an example.  I have observed this behavior in the four versions of ghc that I tried (6.10.4, and 6.12.{1,2,3}).
",blarsen
3,7378,49,"pho@…, hackage.haskell.org@…",Identical alts/bad divInt# code,Compiler,7.6.1,7.8.1,,new,normal,2013-04-12T10:39:19-0700,"[http://stackoverflow.com/questions/13139875/removing-case-with-duplicate-branches-from-haskells-core This] may be the same as #7360, but it may also be a problem in the code generation for `divInt#`. I've reduced it to the following minimal test case:

When compiling

{{{
fun :: Int -> Int
fun i = i `div` 2
}}}

with `ghc -O2 -funfolding-use-threshold=150`, the generated core becomes

{{{
Div2.fun =
  \ (i_aeH :: GHC.Types.Int) ->
    case i_aeH of _ { GHC.Types.I# ww_aiV ->
    case GHC.Prim.># ww_aiV 0 of _ {
      GHC.Types.False ->
        case GHC.Prim.<# ww_aiV 0 of _ {
          GHC.Types.False -> GHC.Types.I# (GHC.Prim.quotInt# ww_aiV 2);
          GHC.Types.True ->
            GHC.Types.I#
              (GHC.Prim.-# (GHC.Prim.quotInt# (GHC.Prim.+# ww_aiV 1) 2) 1)
        };
      GHC.Types.True ->
        case GHC.Prim.<# ww_aiV 0 of _ {
          GHC.Types.False -> GHC.Types.I# (GHC.Prim.quotInt# ww_aiV 2);
          GHC.Types.True ->
            GHC.Types.I#
              (GHC.Prim.-# (GHC.Prim.quotInt# (GHC.Prim.+# ww_aiV 1) 2) 1)
        }
    }
    }
}}}

with two identical `case` alternatives, and in the `True` case, the next comparison is guaranteed to return `False`.

The generated core is good if the divisor is negative, though, so that speaks for taking a look at `divInt#`.",daniel.is.fischer
3,7611,49,"pho@…, hackage.haskell.org@…",Rewrite rules application prevented by type variable application (map id vs. map (\x -> x)),Compiler,7.6.2,7.8.1,,new,normal,2013-04-12T15:57:34-0700,"I’m moving the discussion from 
http://www.haskell.org/pipermail/glasgow-haskell-users/2013-January/023522.html (with reply at http://www.haskell.org/pipermail/glasgow-haskell-users/2013-January/023531.html) here, as a reminder for myself to work on it someday:

Short summary: a rule ""map (\x -> x) = id"" will not match ""map id"" because the latter has (in Core) an application of a type variable, despite the matcher looking through the definition of id. Doing beta-reduction (of type applications) in the matcher could fix this.

I’ll attach a test case.",nomeata
3,7831,49,"pho@…, the.dead.shall.rise@…",Bad fragmentation when allocating many large objects,Runtime System,7.7,7.8.1,ezyang,new,normal,2013-05-13T01:35:12-0700,"Consider our good old friend, the space-leaky list program:

{{{
import Control.Exception
import System.Environment

f n = let xs = [1..n] in sum xs * product xs

main = do
    [n] <- getArgs
    evaluate (f (read n :: Integer))
}}}

It is not surprising that this program is quite the memory guzzler; what is surprising is how much GHC *wastes* when evaluating this program:

{{{
Fragmentation, wanted 95 blocks,  105 MB free
}}}

(For reference, a block is 4k, so 95 blocks is a measly 380k!)  The magnitude of the problem can be seen in this graphic:

[[Image(http://web.mit.edu/~ezyang/Public/fragmentation-ghc.png)]]

(The x-axis takes advantage of the fact that the number of requested blocks increases ~linearly over time, since we keep multiplying the integer which adds a constant number of extra bytes to the representation; unused free memory corresponds to blocks of free memory in GHC's free list, which it is holding onto from the OS but not using to store user data.)

When the requested allocations are *just* large enough (just slightly over half a megablock, or 128 blocks), we start allocating a megablock per allocation and waste half of the megablock, since none of the leftovers are ever large enough to store any of the later allocations.

Can we do anything about this? One possibility is to occasionally check how much space we're losing to fragmentation, and everyone once in a while pay the cost of copying tenured large objects and pack them together in a megablock group (obviously one wants to avoid doing this too often, since copying large objects is expensive!) I'm open to better suggestions though! (Apologies if this is a duplicate; I didn't see any open tickets with the word ""fragmentation"" in them).",ezyang
3,3647,49,"erik.flister@…, michal.terepeta@…",unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions,Compiler (Parser),6.10.4,7.8.1,igloo,new,normal,2012-10-25T09:28:53-0700,"it's easy to accidentally cut and paste a -XExtentionName from a ghc error message into one's  {-#LANGUAGE ...#-} pragma, and then one has to track down the problem when that doesn't work.  it would be nice if -XExtentionName were accepted in the pragma list.  even though -X is ghc specific, i don't see that it hurts anything to be lenient in the pragma format accepted (a warning could be produced to indicate that the program will not be portable).  also, the ghc error message indicating that an extension should be added should print out a message that would make for easy cut and paste without modification into *either* one's language pragma or command line -X extension args.  see http://hackage.haskell.org/trac/ghc/ticket/3616#comment:8.",eflister
3,1399,49,claus.reinke@…,better support for developing threaded applications in ghci,GHCi,6.6.1,_|_,,new,normal,2009-04-11T14:23:24-0700,"The haskell threads model has the appealingly simple property that the main thread determines the lifetime of your program. Once the main thread completes, all other threads are killed.

However this doesn't apply when iteratively developing at the ghci command-line. If, for example, you run `main` from the ghci prompt, you regain control of the prompt when your main thread terminates, but any threads spawned by it will keep running. This is particularly irksome if some of them hold onto OS resources (e.g. listening TCP sockets) as you find you can't run your code more than once due to resource issues.

It is possible to solve this problem explicitly by killing all the threads yourself at the end of `main`, but that amounts to adding a special `ghci` workaround to your code, because you wouldn't need that to compile as a standalone application.

I don't have a specific proposal on the best solution. One would be to alter `ghci`'s semantics so that after the completion of every interactively entered `IO a` action you reap all new threads that have been created. The disadvantage of this would be that it inhibits some interesting kinds of debugging exploring where you deliberately fork some threads from ghci and then communicate with them.

A more general solution would be some kind of `:command` to run either with-or-without the reaper-like function as preferred.",guest
3,2742,49,"cgibbard@…, hackage.haskell.org@…",The -> in ViewPatterns binds more weakly than infix data constructors.,Compiler,6.10.1,_|_,,new,normal,2013-03-24T23:44:11-0700,"The following code, essentially taken from the ViewPatterns page on the wiki doesn't seem to parse correctly.

{{{
mymap f [] = []
mymap f (x : mymap f -> xs) = f x : xs
}}}

However, this does:

{{{
mymap f [] = []
mymap f (x : (mymap f -> xs)) = f x : xs
}}}

(though it triggers bug #2395 about overlapping patterns)

It would seem nicer to make the view pattern arrow bind ''tighter'' than any infix data constructors.",guest
4,4215,49,"pho@…, the.dead.shall.rise@…",canonicalizePath behaves strangely with paths that do not exist,libraries/directory,6.12.3,7.6.2,,new,low,2013-04-25T05:01:15-0700,"The behavior of System.Directory.canonicalizePath is not documented (and perhaps not defined) for paths that do not exist on the file system.  The documentation should, minimally, indicate that this is the case.  Ideally, the behavior would be well-defined.

This is complicated by differing behaviors of the underlying realpath(char*, char*) function in Linux and OS X.  On Linux, realpath changes its behavior if the last existing portion of the input path is a file vs. a directory, while OS X does not alter behavior in these two cases.  Specifically, assume the following:

 * $HOME/tmp/foo is a file.
 * $HOME/tmp/bar is a directory.
 * $HOME/tmp/baz does not exist.

Linux:
{{{
Prelude System.Directory> canonicalizePath ""/home/creswick/tmp/foo/subdir""
""/home/creswick/tmp/foo""
Prelude System.Directory> canonicalizePath ""/home/creswick/tmp/bar/subdir""
""/home/creswick/tmp/bar/subdir""
Prelude System.Directory> canonicalizePath ""/home/creswick/tmp/baz/subdir""
""/home/creswick/tmp/baz""
}}}

OS-X:
{{{
Prelude System.Directory> canonicalizePath ""/Users/hudson/tmp/foo/subdir""                                                           
""/Users/hudson/tmp/foo/subdir""
Prelude System.Directory> canonicalizePath ""/Users/hudson/tmp/bar/subdir""
""/Users/hudson/tmp/bar/subdir""
Prelude System.Directory> canonicalizePath ""/Users/hudson/tmp/baz/subdir""
""/Users/hudson/tmp/baz""
}}}
",creswick
4,5063,49,"leon.p.smith@…, v.dijk.bas@…, bos",unix package has untracked dependency on libbsd,libraries/unix,7.0.3,7.6.2,,new,low,2012-09-12T04:13:26-0700,"See ticket #4974 about unix-compat failing to build.

That is just a symptom. The real problem is that the unix package installs a HsUnix.h file which is broken on some target platforms, standard linux platforms.

HsUnix.h contains:
{{{
#ifdef HAVE_LIBUTIL_H
#include <libutil.h>
#endif
}}}

If the system that the package is built on has libbsd installed then it'll use it. But if the target system does not have this C lib then the HsUnix.h header is broken on such systems.

Why does the unix package optionally depend on libbsd? Is it really needed?

If it is needed then the distro packages need to be modified so that the unix package has dependency on libbsd-dev.

This raises another issue: we should be able to check that all the headers we install on a target actually work on that target. This check should be run as part of the ghc and HP release testing process.",duncan
4,3645,49,"erik.flister@…, michal.terepeta@…",Layout and pragmas,Compiler (Parser),6.10.4,7.6.2,,new,low,2012-09-12T04:12:18-0700,"With this module:
{{{
{-# LANGUAGE DeriveDataTypeable,
             FlexibleContexts
#-}

module Foo where
}}}
GHC 6.12 says:
{{{
    Cannot parse LANGUAGE pragma
    Expecting comma-separated list of language options,
    each starting with a capital letter
      E.g. {-# LANGUAGE RecordPuns, Generics #-}
}}}
but this should probably be allowed. See #3519, #3616.
",igloo
4,4426,49,"fischer@…, id@…",Simplify the rules for implicit quantification,Compiler,6.12.3,7.6.2,,new,low,2012-09-12T04:12:31-0700,"This thread http://www.haskell.org/pipermail/glasgow-haskell-users/2010-October/019360.html
convinced me that GHC's rules for implicit quantification are unnecessarily complicated.

-------------
== The current spec ==
The current spec seems to be this:
 * Define an ""implicit quantification point"" to be (a) the type in a type signature `f :: type` if `type` does not start with `forall`;  or (b) a type of form `(context => type)`, that is not immediately enclosed by an explicit `forall`

 * At each implicit quantification point 'ty', working outside in, GHC finds all the type variables a,b,c in 'ty' that are not already in scope, and transforms 'ty' to (forall a,b,c. ty).

Note that
 * The argument of a constructor is not an implicit quantification point, so that
{{{
data Foo = MkFoo (a -> a)
}}}
 is an error, and does not mean
{{{
data Foo = MkFoo (forall a. a->a)
}}}

 * Implicit quantification points may be nested but the inner ones are effectively no-ops.  Example
{{{
f :: Int -> (Eq a => a -> a) -> Int
}}}
  There are two quantification points: the whole type, and the `(Eq a => ...)`. But when the outer quantification point wraps forall a around it, the inner quantification point has no free variables to quantify. So we get
{{{
f :: forall a. Int -> (Eq a => a -> a) -> Int
}}}

--------------
== The new proposal == 

The proposed new rule is this:
 * Implicit quantification applies only to an entire user type signature that does not start with `forall`.
 * For such signatures, find all the type variables a,b,c in the signature that are not already in scope, and prefix the signature with `forall a,b,c.`

I believe that the only observable changes in behaviour would be
 * In a data type declaration
{{{
data Foo = MkFoo (Eq a => a -> a)
}}}
 you'd get an error ""a is not in scope"", just as you would with
{{{
data Foo = MkFoo (a->a)
}}}
 To me this seems more consistent behavour.

 * Inside an ''explicit'' `forall` you would get no ''implicit'' `foralls`:
{{{
f :: forall a. (Eq b => b->b) -> a -> a
}}}
 would yield ""b is not in scope"", whereas at present it behaves like
{{{
f :: forall a. (forall b. Eq b => b->b) -> a -> a
}}}",simonpj
5,2648,49,"pho@…, hackage.haskell.org@…",Report out of date interface files robustly,GHCi,7.6.3,7.6.2,,new,lowest,2013-05-03T03:56:54-0700,"Suppose `X.hi` refers to `Y.f77`, but `Y.hi` is out of date and has no `f77`. Then you get a bad crash:
{{{
(GHC version 6.8.3 for i386-unknown-mingw32):
    tcIfaceGlobal (local): not found:
Please report this as a GHC bug
}}}
The solution lies within our grasp:
 * X.hi already contains a fingerprint for Y.hi
 * So, we should simply check Y.hi's fingerprint when we suck it in
(Currently we do this fingerprint checking only for the module we are currently compiling, to see if the bits it depends on have changed.)

Simon",simonpj
3,3971,48,"mikolaj.konarski@…, mle+hs@…",FFI callback segfaults on PPC,Compiler (FFI),6.12.3,_|_,,new,normal,2011-04-10T16:30:24-0700,"ghc-pkg has been segfaulting ever since I installed ghc-6.12.1.20100330 on my G5 PowerPC running gentoo 32-bit userland; current state:

{{{
/usr/local/packages/ghc-6.12.1.20100330/lib/ghc-6.12.1.20100330/package.conf.d
   Cabal-1.8.0.3
   QuickCheck-2.1.0.3
   array-0.3.0.0
   base-3.0.3.2
   base-4.2.0.1
   bin-package-db-0.0.0.0
   binary-0.5.0.2
   bytestring-0.9.1.6
   containers-0.3.0.0
   directory-1.0.1.1
   Segmentation fault
}}}

(Now, trying to install zlib, I also get:
{{{
 ./Setup configure --prefix=/usr/local/packages/ghc-6.12.1.20100330 -p
Configuring zlib-0.5.2.0...
Setup: failed to parse output of 'ghc-pkg dump'
}}}
although I can see nothing wrong with the output of 'ghc-pkg dump' &mdash; reported under [http://hackage.haskell.org/trac/hackage/ticket/599 Bug 559 in the Cabal trac].)

Wolfram",wkahl
2,7056,47,"sun.april.moon@…, jonas.fager@…","GHCi loadArchive ""libiconv.a"":failed Unknown PEi386 section name `.drectve'",GHCi,7.4.1,7.6.2,,new,high,2013-04-14T07:44:03-0700,"
cygwin 1.7
{{{
$ iconv --version
iconv (GNU libiconv 1.14)
}}}

E:/Develop/haskell/conv.hs :
{{{
import Codec.Text.IConv as IConv
import Data.ByteString.Lazy as ByteString

main :: IO ()
main = ByteString.interact (convert ""UTF-8"" ""GBK"")        
}}}

then 

{{{
GHCi, version 7.4.1: 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> :load ""e:/Develop/haskell/conv.hs""
[1 of 1] Compiling Main             ( E:\Develop\haskell\conv.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
Loading package bytestring-0.9.2.1 ... linking ... done.
Loading package iconv-0.4.1.0 ... ghc.exe: panic! (the 'impossible' happened)
  (GHC version 7.4.1 for i386-unknown-mingw32):
	loadArchive ""d:/cygwin/lib\\libiconv.a"": failed

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

*Main> Leaving GHCi.
<interactive>: Unknown PEi386 section name `.drectve' (while processing: d:/cygwin/lib\libiconv.a)
}}}

",songpp
3,5498,47,"dimitris@…, sweirich@…",Generalized newtype deriving allows creating of instances I can't create by hand,Compiler,7.3,7.6.2,,new,normal,2012-09-12T04:12:04-0700,"First here is a simple module that establishes a list where once created (with a min element) subsequent elements inserted should always be larger than the min:

{{{
-- | Here we expose a MinList API that only allows elements
-- to be inserted into a list if they are at least greater
-- than an initial element the list is created with.
module MinList (
        MinList,
        newMinList,
        insertMinList,
        printIntMinList
    ) where

data MinList a = MinList a [a]

newMinList :: Ord a => a -> MinList a
newMinList n = MinList n []

insertMinList :: Ord a => MinList a -> a -> MinList a
insertMinList s@(MinList m xs) n | n > m     = MinList m (n:xs)
                                 | otherwise = s

printIntMinList :: MinList Int -> IO ()
printIntMinList (MinList min xs) = putStrLn $ ""MinList Int :: MinList "" ++ show min ++ "" "" ++ show xs
}}}

Now I import this module and use generalized newtype deriving to create a function I couldn't create by hand:
{{{
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
-- | We use newtype to create an isomorphic type to Int
-- with a reversed Ord dictionary. We now use the MinList
-- API of MinList to create a new MinList. Then we use newtype
-- deriving to convert the newtype MinList to an Int
-- MinList. This final result breaks the invariants of
-- MinList which shouldn't be possible with the exposed
-- API of MinList.
module Main where

import MinList

class IntIso t where
    intIso :: c t -> c Int

instance IntIso Int where
    intIso = id

newtype Down a = Down a deriving (Eq, IntIso)

instance Ord a => Ord (Down a) where
    compare (Down a) (Down b) = compare b a

fine :: MinList (Down Int)
fine = foldl (\x y -> insertMinList x $ Down y) (newMinList $ Down 0) [-1,-2,-3,-4,1,2,3,4]

bad :: MinList Int
bad = intIso fine

main = do
    printIntMinList bad
}}}

The problem here is the isoInt method where I can do:
{{{
isoInt :: MinList (Down Int) -> MinList Int
}}}
which I shouldn't be able to do since I don't have the constructors for `MinList`.

This is the reason I've currently disabled newtype deriving in Safe Haskell but potentially we can enable it if this bug is fixed.",dterei
3,7619,47,"jwlato@…, hackage.haskell.org@…",Make worker-wrapper unbox data families,Compiler,7.7,7.8.1,simonpj,new,normal,2013-04-12T16:03:38-0700,"I noticed that the worker-wrapper optimization doesn't unbox arguments whose type is a data family instance. For example in this module:

{{{
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE BangPatterns #-}
module Foo where
data family Foo a

data instance Foo Int = FooInt Int Int

foo :: Foo Int -> Int
foo (FooInt a b) = loop a b
    where
        loop 0 y = length $ replicate y b
        loop x !y = loop (mod y x) x

foo1 :: (Int, Int) -> Int
foo1 (a, b) = loop a b
    where
        loop 0 y = length $ replicate y b
        loop x !y = loop (mod y x) x
}}}

foo and foo1 both get worker-wrapper applied, with worker functions of the following types:

{{{
$wfoo :: Foo Int -> Int#
$wfoo1 :: Int# -> Int# -> Int#
}}}

It would be nice if $wfoo could get the same type as $wfoo1.

This issue happened in real life with unboxed vectors from the vector package, resulting in a lot of boxing with unboxed vector constructors immediately followed by unboxing.",akio
3,947,47,"hackage.haskell.org@…, jwlato@…",ghc -O space leak: CSE between different CAFs,Compiler,6.5,_|_,,new,normal,2012-10-15T17:13:34-0700,"Consider the following program for generating the 1,000,000th prime:

{{{
module Main (main) where

sieve0 (n:ns) (p:ps)
    | p*p == n  = sieve0 (filter (\n -> n`mod`p /= 0) ns) ps
    | otherwise = n:sieve0 ns (p:ps)

primes0 :: [Int]
primes0 = 3:sieve0 [5,7..] primes0

primes :: [Int]
primes = 2:3:sieve0 [5,7..] primes0

main = print $ primes !! 1000000
}}}

The intention of the separate primes0 function is to limit the number of primes that need to be held in memory. Unfortunately, ghc -O combines the common subexpressions in primes0 and primes so this effort is wasted. The resulting program needs noticably more memory than required, as can be seen by replacing the definition of {{{primes}}} by

{{{
primes = 2:3:sieve0 (iterate (2+) 5) primes0
}}}

which prevents the CSE from happening.

Excerpt of {{{+RTS -s}}} output, original version:
{{{
12,099,221,160 bytes allocated in the heap
279,720,116 bytes copied during GC
 15,834,912 bytes maximum residency (6 sample(s))
}}}
modified version that prevents CSE:
{{{
127,736,408 bytes copied during GC (scavenged)
    233,388 bytes copied during GC (not scavenged)
     30,624 bytes maximum residency (1 sample(s))
}}}

Tested with ghc 6.4.2 and a current (as of 2006-10-17) darcs ghc 6.5.",int-e@…
3,7883,46,"carter.schonwald@…, pho@…",enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives?,Compiler,7.7,,carter,new,normal,2013-05-20T02:39:02-0700,"LLVM provides a number of atomicity / memory ordering primitives.

currently the CAS primops exposed at the CMM level are ffi'd inline assembly fun calls. this means that for certain concurrency primops, we've got fun calls within funcalls that could be easily inlined if we did it in a more llvm direct way. A notable example of this is the implementation of {{{ stg_atomicModifyMutVarzh }}}


relevant basic llmv docs are the following
[http://llvm.org/docs/LangRef.html#cmpxchg-instruction Atomic llvm ops]

[http://llvm.org/docs/Atomics.html semantics of the various ordering levels]

relevant locations in the ghc source
[https://github.com/ghc/ghc/blob/master/includes/stg/SMP.h#L170 CAS inline assembly]

[https://github.com/ghc/ghc/blob/master/rts/PrimOps.cmm#L282 defn of atomicModifyMutVar cmm code]


Based upon my reading of the relevant GHC cmm code, and reading the semantics of the LLVM operations, the right level of atomic ordering in the generated bit code would be ""SequentiallyConsistent"".

a first step would be to modify the CMM -> LLVM pass to substitute the cas funcall with the right llvm operation.  This ''' SEEMS ''' like it'd be very very easy to do and low hanging fruit.  

Theres a few upsides that ''' might ''' come out of this. 

 1.  would be easy to augment to also provide a doubleCAS primitive, which would  be useful in writing various lock free data structures.
 2.  would increase the portability  / ease of retargeting  new platforms / hardware via LLVM. (not needing to worry about the target's memory consistency model / write new cases of inline assembly)
 3.  (this would need benchmarks) could potentially improve the performance of certain heavy concurrency operations by eliminating a funcall in an otherwise tight loop.
 4. Theres probably other interesting possible upside, such as perhaps having more of the rts be nicely writeable in CMM? (esp since theres now native funcall support)
 5. Also would make the CMM memory model a bit more explicit perhaps?
 

This seems like a *relatively* managable patch to write. I'm up for spending time on this if, should it work, it'd be likely to be merged in.

it'd also be a good warm up for a number of other things I want to do, including http://hackage.haskell.org/trac/ghc/ticket/5567#comment:10 

",carter
2,5019,45,"gale@…, william.knop.nospam@…",OS X: ld: warning: could not create compact unwind for _ffi_call_unix64,Compiler,7.1,7.8.1,,new,high,2012-11-17T07:49:45-0800,"The OS X 10.6 linker now defaults to creating compact unwinds, which is a good thing, however the unwind info for `_ffi_call_unix64` can't be represented in the compact format. This warning is issued any time ghc links, and many tests in the test suite fail due to the extra output:

{{{
ld: warning: could not create compact unwind for _ffi_call_unix64: does not use RBP or RSP based frame
}}}

Possible solutions:
 * suppress the warning in ld; unfortunately this does not seem to be possible, since the only applicable option is `-warn_compact_unwind` which enables the already enabled-by-default warnings
 * suppress the warning in ghc; I haven't really looked into this, but one could filter the text output from the linker to remove the warning
 * entirely disable compact unwinds using `-no_compact_unwind`; this flag is undocumented, so I'm not certain about what it really does
 * patch `_ffi_call_unix64` in libffi to make it compatible with compact unwinds

Info about compact unwinds in OS X 10.6 is somewhat scarce, but `man unwinddump` has a bit:
{{{
When a C++ (or x86_64 Objective-C) exception is thrown, the runtime must unwind the
stack looking for some function to catch the exception.  Traditionally, the unwind
information is stored in the __TEXT/__eh_frame section of each executable as Dwarf
CFI (call frame information).  Beginning in Mac OS X 10.6, the unwind information is
also encoded in the __TEXT/__unwind_info section using a two-level lookup table of
compact unwind encodings.

The unwinddump tool displays the content of the __TEXT/__unwind_info section.
}}}

Relevant discussions:

[http://groups.google.com/group/llvm-dev/browse_thread/thread/8baba4531a9feb07/139c9eba3525ebe]
[http://groups.google.com/group/darwin-dev/browse_thread/thread/962f74bde0efaae4/cfb63dfb3ac34ce1]
",altaic
2,7229,45,"andersk@…, anton.nik@…, dcoutts",Detecting if a process was killed by a signal is impossible,libraries/process,,7.8.1,,new,high,2012-11-17T09:47:34-0800,"Currently there is no good way of detecting if a process was terminated by a signal. We have the following problems:

 * Firstly, the API doesn't make any allowance for it. This may be because the concept doesn't exist on Windows, I'm not sure. But since the concept ''does'' exist on POSIX, we do have to make a decision about what to do there (or if we have made one, document it).
 * `waitForProcess` attempts to give the signal in the exit code, but the underlying C function doesn't use the `WTERMSIG` macro. It so happens that on my system it works fine anyway, but it has no ''right'' to in principle (and in any case, what it does is both sub-optimal (in that getting killed by SIGINT is indistinguishable from returning 3) and undocumented).
 * The C function `getProcessExitCode` is much worse. When a process has exited due to a signal, it tests `WIFSIGNALED`, and if true, sets `errno = EINTR` (huh?) and returns `-1`. Since it is called from `throwErrnoIfMinus1Retry`, the result is that it immediately gets called again: but this time the child doesn't exist anymore. The behaviour in the case of `ECHILD` is, bizarrely, to pretend that there was a child and it exited with status 0, i.e. success. Which is just untrue.

I don't know what the right behaviour is, but the above is both inconsistent and unhelpful. The lack of `WTERMSIG` is easily fixed, but that's the least of the problems here: we really need to work out what ''ought'' to happen before we start making it happen.",benmachine
2,7651,45,"pho@…, andreas.voellmy@…",Buiding GHC with parallel IO manager freezes on Mac (not on FreeBSD),Build System,7.7,7.8.1,,new,high,2013-04-12T16:58:37-0700,"Building GHC with parallel IO manager on Mac freezes when
compiling the dph libraries in the phase 2.

We '''suspect this is due to a bug in the OS X implementation of kqueue''', for the reasons given below.  In the meantime, we have added an extra IO manager wakeup that appears to work around the problem; see `GHC/Event/Manager.hs`.

Details:

 * This happens only if we specify ""-j"" to ""make"". Note that ""make"" closes stdin of sub-processes if ""-j"" is specified.

 * Even if we specify ""-j"" to ""make"", the problem disappears with stdout/stderr redirection. That is, ""make -jN >& LOG &"" works.

 * The ""-d"" option of ""make"" does not make any effects.

 * Programs compiled with built GHC (with our patches) work well. For test, I compiled a daemon HTTP server which closes stdin/stdout/stderr. It worked well.

An IO manager is polling a kqueue fd. Another Haskell thread on
another native thread registers an event through the same kqueue
fd.  In many cases, this works on Mac. In a certain situation,
MacOS does not deliver an event to the IO manager. If the IO
manager gets up and polls the kqueue fd, the event is delivered.

This bug only appears when building GHC on Mac. I cannot find a
simple way to reproduce it. Even if we find a way to reproduce
it, I guess that we will probably reach a conclusion that this is
a bug of kqueue of Mac.

I have some evidences that kqueue of Mac is buggy:

 * http://comments.gmane.org/gmane.comp.lib.ev/1871
 * http://lists.apple.com/archives/darwin-dev/2011/Jun/msg00016.html
",kazu-yamamoto
3,4268,45,"bgamari@…, juhp@…",Annotation extension needs a flag,Compiler,7.0.4,7.6.2,,new,normal,2012-12-05T20:19:47-0800,"There's no flag to enable the annotations extension, as far as I can tell.",simonmar
3,5435,45,"howard_b_golden@…, pho@…",GHCi linker should run constructors for linked libraries,Compiler,7.2.1,7.8.1,,new,normal,2012-11-07T09:51:04-0800,"As far as I can tell from my experimentation, any library that contains a function with __attribute__((constructor)) on it won't have its constructor(s) run when loaded, or its destructors run when unloaded. This violates assumptions that some libraries make.",pumpkin
3,7258,45,"iustin@…, pho@…, dterei",Compiling DynFlags is jolly slow,Compiler,7.6.1,7.8.1,simonpj,new,normal,2013-01-31T11:02:49-0800,"Compiling `DynFlags` really takes a long time these days.  

Ian thinks that it's due to the `Read` and `Show` instances he has added (see attached `W2.hs`.

Simon M suggests: instead of using `Read/Show`, you could generate some code in `mkDerivedConstants` to use `ReadP` and `Outputable`, which should be much smaller and faster.

This ticket is
 * To see if we can speed up compilation of `DynFlags` 
 * To check WHY it is so slow.  Are there any lessons we can learn or ways to make it compile faster?  Is it tickling some asymptotically-bad corner of the compiler?

Simon",simonpj
3,1830,45,"alfonso.acosta@…, vogt.adam@…",Automatic derivation of Lift,Template Haskell,6.8.1,_|_,,new,normal,2013-01-26T15:47:55-0800,"This feature request was brought up in this template-haskell thread[1]:

There are apparently two implementation alternatives:

1) Merge Ian's th-lift library[2] with the mainstream template-haskell library

2) Implement ""instance Data a => Lift a"" (requires allowing undecidable and overlapping instances) in template-haskell. Since Data can be derived automatically by GHC, such an instance would imply automatic derivation of Lift as well.

[1] http://www.haskell.org/pipermail/template-haskell/2007-October/000635.html
[2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/th-lift-0.2",guest
3,701,45,"Bulat.Ziganshin@…, pho@…",Better CSE optimisation,Compiler,6.4.1,_|_,michalt,new,normal,2013-01-20T21:43:22-0800,"GHC's CSE optimisation is pretty weedy.  It looks for expressions like this: 
{{{
   let x = e1 in e2
}}}
and replaces all occurrences of e1 in e2 with x.  This doesn't do full CSE, but it does catch some cases.  There have been case where full CSE would be significantly beneficial, though.

One possible way forward is to have a separate CSE pass that transformed expressions containing common subexpressions into the let-form above, and let the existing CSE pass do the final replacement.

We must be cautious, though: increasing sharing can introduce space leaks.  Sometimes we can prove that this cannot happen, for example when the shared object is primitive, or has a bounded size.",simonmar
4,4049,45,"nbowler@…, howard_b_golden@…",Support for ABI versioning of C libraries,Build System,6.12.2,7.6.2,,new,low,2012-09-12T04:12:24-0700,"Currently the SO files can be versioned - like in libgtk-x11-2.0.so.0. However GHC provides no support for such versioning which may cause problems if the ABI of library will change.

Also it does not provide any support for ldscripts and fails if it seeks for libz.so and only found is ldscript.

More informations:
http://bugs.gentoo.org/show_bug.cgi?id=290974
http://bugs.gentoo.org/show_bug.cgi?id=311361",uzytkownik
5,2526,45,"pho@…, andy.adamsmoran@…",warn about missing signatures only for exported functions,Compiler,6.8.3,7.6.2,,new,lowest,2013-02-02T19:29:14-0800,"The -fno-warn-missing-signatures option results in warnings if signatures are not declared for any top-level functions.

Many Haskell users prefer to declare type signatures only for exported functions, which are part of the module's interface, not for all functions.  It would be nice to have an option that issued warnings iff any exported functions lacked explicit signatures.",fergushenderson
2,7602,44,"johan.tibell@…, chak@…",Threaded RTS performing badly on recent OS X (10.8?),Runtime System,7.7,7.8.1,thoughtpolice,new,high,2013-06-12T13:05:45-0700,"This ticket is to remind us about the following problem: OS X is now using llvm-gcc, and as a result GHC's garbage collector with -threaded is much slower than it should be (approx 30% slower overall runtime).  Some results here: [http://www.haskell.org/pipermail/cvs-ghc/2011-July/063552.html]

This is because the GC code relies on having fast access to thread-local state.  It uses one of two methods: either a register variable (gcc only) or `__thread` variables (which aren't supported on OS X).  To make things work on OS X, we use calls to `pthread_getspecific` instead (see #5634), which is quite slow, even though it compiles to inline assembly.

I don't recall which OS X / XCode versions are affected, maybe a Mac expert could fill in the details.

We have tried other fixes, such as passing around the thread-local state as extra arguments, but performance wasn't good. Ideally Apple will implement TLS in OS X at some point and we can start to use it.

A workaround is to install a real gcc (using homebrew?) and use that to compile GHC.  Whoever builds the GHC distributions for OS X should probably do it that way, so everyone benefits.
",simonmar
3,3231,44,"ndmitchell@…, lennart@…",Permission denied error with runProcess/openFile,libraries/base,6.10.4,7.6.2,simonmar,new,normal,2012-09-12T04:11:58-0700,"Given this program:

{{{
module Main() where

import Control.Concurrent
import System.IO
import System.Process

main = do
    hSetBuffering stdout NoBuffering
    forkIO $ f ""foo1.txt""
    forkIO $ f ""foo2.txt""
    threadDelay $ 100*1000000
    putStrLn ""Finished successfully""

f file = do
    h <- openFile file AppendMode
    hPutStrLn h ""fakdjsklj""
    putChar '.'
    pid <- runProcess ""sh"" [""-c"",""sleep 0.1s""] Nothing Nothing Nothing (Just h) (Just h)
    waitForProcess pid
    f file
}}}

Running under Cygwin, in GHC 6.10.2, I get:

{{{
$ runhaskell Test.hs
..Test.hs: foo1.txt: openFile: permission denied (Permission denied)
}}}

It shouldn't - the {{{openFile}}} calls should always succeed. This bug is a reduced test case from a real system, which I papered over with:

{{{
retryIO :: IO a -> IO a
retryIO act = catchIO act $ \x -> do
    threadDelay $ 1 * 1000000 -- 1 second
    performGC
    act
}}}

Now calling {{{retryIO $ openFile ...}}} works reliably. These problems are occurring sufficiently often that {{{retryIO}}} is about to go in to our standard library :-)

This may be related to #2924, but has the advantage of replicating easily.",NeilMitchell
4,1498,44,"ndmitchell@…, johan.tibell@…",Optimisation: eliminate unnecessary heap check in recursive function,Compiler,6.6.1,7.6.2,,new,low,2013-01-22T11:41:47-0800,"See [http://www.haskell.org/pipermail/cvs-ghc/2007-July/036496.html]

In a basic block consisting of some primitive cases, in which only some branches require heap, we could push the heap check into the branches as long as the primitive operations are safe to repeat, and the stack has not been modified.  This might save a heap check in the common recursive case, which could be a significant win.",simonmar
4,4942,44,"lightwing15@…, fryguybob@…",GHC.ConsoleHandler does not call back application when Close button is pressed,GHC API,6.12.3,7.6.2,,new,low,2012-09-12T04:13:24-0700,"The test program below is not called back by GHC.ConsoleHandler when the Close button is pressed during the threadDelay call. A message is written to console_event.log as expected when Ctrl-C or Ctrl-Break is pressed, but not when the Close button is pressed.

{{{
import Control.Concurrent (threadDelay)
import GHC.ConsoleHandler
import System.IO

onConsoleEventReceived :: ConsoleEvent -> IO ()
onConsoleEventReceived event = withFile ""console_event.log"" AppendMode $ \ file -> do
  hPutStrLn file $ case event of
    ControlC  -> ""Received Ctrl-C event""
    Break     -> ""Received Ctrl-Break event""
    Close     -> ""Received X button event""
    _         -> ""Received other console event""
  hFlush file
    
main :: IO ()
main = installHandler (Catch onConsoleEventReceived) >> threadDelay (20*1000000)
}}}

The host OS is Windows XP SP3.

Please let me know if you need any more info.",Amatic
4,5073,44,"wadler@…, Matthew.Fluet@…",Add blockST for nested ST scopes,Compiler,7.0.3,7.6.2,,new,low,2012-09-12T04:13:27-0700,"GHC lacks the `blockST` and `importVar` primitives introduced by Launchbury/Sabry:
 * http://www.cs.indiana.edu/~sabry/papers/monadic-state-ax.pdf (section 10).  
 * See also Fluet & Morrisset http://www.cs.rit.edu/~mtf/research/rgn-monad/JFP06/jfp06.pdf (page 7ff)

The two new combinators have these types:
{{{
blockST :: (forall r. ST (s,r) a) -> ST s a
importVar :: STRef s a -> STRef (s,r) a
}}}
They are useful, and have no runtime cost; I don't think it'd be hard to provide them.  We need these primitives, I think:
{{{
promoteState# :: State# s -> State# (s,r) a
demoteState#  :: State# (s,r) -> State# s
promoteVar# :: MutVar# s a -> MutVar# (s,r) a
}}}
All three are implemented as no-ops.  (Compare with `newMutVar#` etc in http://darcs.haskell.org/ghc/compiler/prelude/primops.txt.pp.)

Now the implementations look (something) like this. (For background see the current impementations of `ST` and `STRef` in http://darcs.haskell.org/packages/base/GHC (`ST.lhs` and `STRef.lhs` resp.)
{{{
blockST (ST thing) = ST (\s -> case thing (promoteState# s) of
                                 (s', r) -> (demoteState# s', r) )
promoteVar (STRef r) = STRef (promoteVar# r)
}}}
Things to think about:
 * Can we use coercions instead of primops?   (I think yes for `promote/demoteState` but it's unsound to demote variables.)
 * I'm hazy about what type safety guarantees we still have in Core, where the representation of the state monad is exposed.
 * Nomenclature. I'm not attached to these particular names.
 * Is there other relevant background material?",simonpj
4,1476,44,"alfonso.acosta@…, pho@…",Template Haskell: splicing types and patterns,Template Haskell,6.6.1,_|_,,new,low,2013-01-22T08:18:59-0800,"In http://www.haskell.org/pipermail/template-haskell/2003-February/000021.html Simon Peyton Jones writes:
{{{
We claim to allow you to write splices in (a) types and (b) patterns.
I'm very dubious about (b). Consider]
    x = 4
      
    y :: Patt 
    y = [p| ... |]

    f $y = x

Question: where is x bound?  It looks as though x can be bound by the
spliced-in pattern or by the top-level binding.  You can't tell without
knowing what $y expands to.  We argue in our paper against non-top-level
declaration splices because that would lead to ambiguity of exactly this
sort.

It turns out that it's very inconvenient to implement pattern splices in
GHC, for exactly this reason.  We can't figure out the binding structure
till we expand the splice.  We can't expand the splice till typechecking
time.  But the renamer currently fixes the binding structure before type
checking.    Changing this would be a big upheaval.

Conclusion: pattern splices are hard to implement, and dubious from a
programming point of view.  I propose to drop them, for now at least.


Type splices have some similar echoes.  Consider
      
    y :: Type 
    y = [t| a -> a |]

    f :: $y

What is f polymorphic in?   The trouble concerns Haskell's implicit
quantification.  I guess there are three possibilities:

a) $y expands to ""a -> a"", and that is implicitly universally quantified
to ""forall a. a->a"".
b) The implicit quantification happens at the [t| ...|] brackets, so
that $y expands to
    ""forall a. a->a""
c) $y expands to ""a -> a"" with no implicit quantification anywhere.

I'm pretty sure that we should adopt (b).  After all, we want a
lexical-scoping rule for TH, so we have to say where 'a' is bound.

That would still in principle allow
      
    y :: Type
    y = return (Tvar ""a"" `Arrow` Tvar ""a"")

Since it's the renamer that does implicit quantification, it'd be quite
awkward to make the implicit quantification at the splice site ""see"" the
free variables 'a'.

The link with the pattern stuff is this.  If you see
    f :: $y -> b

then what are the implicit for-alls?  My answer: the implicit for-alls
are just for ""b"", not for any free vars of $y.
}}}

Since then, the only solution for pattern splices I recall seeing is
{{{
f ${x,z}y = x
}}}
which asserts that the splice introduces the set of identifiers `{x,z}`.",igloo
5,2600,44,"pho@…, mail@…",Bind type variables in RULES,Compiler,6.8.3,7.6.2,simonpj,new,lowest,2013-02-02T19:51:30-0800,"Roman writes: here's an example I came across while working on the recycling paper
and which I subsequently forgot about. Suppose we have:
{{{
{-# LANGUAGE Rank2Types #-}
module T where

class T t where
   to   :: [a] -> t a
   from :: t a -> [a]
   tmap :: (a -> a) -> t a -> t a

{-# RULES

""myrule"" forall f x.
     from (tmap f (to x)) = map f (from (to x))
  #-}
}}}
Alas, this fails with:
{{{
     Ambiguous type variable `t' in the constraint:
       `T t' arising from a use of `to' at T.hs:12:40-43
     Probable fix: add a type signature that fixes these type variable(s)
}}}
Of course, I'd like the t on the rhs to be the same as on the lhs but
I don't see how to tell this to GHC. Is it actually possible? The only
solution I've found was to add a dummy argument to 'to':
{{{
to' :: t a -> [a] -> t a

to = to' undefined

{-# RULES

""myrule"" forall f t x.
     from (tmap f (to' t x)) = map f (from (to' t x))
  #-}
}}}
That's ugly, of course. Am I missing something or is this just
impossible to do with the current system?
",simonpj
5,1572,44,"claus.reinke@…, alpmestan@…",Make it easy to find documentation for GHC and installed packages,Compiler,6.6.1,7.6.2,,new,lowest,2013-01-26T12:01:15-0800,"`ghc-pkg` builds a package database that helps GHC find all installed packages.  But it'd be a great improment if the same step also helped the '''user''' find the Haddock documentation for all installed packages.

Corresponding to GHC's package database would be an HTML page that is a single point of entry for the user to find documentation about installed packages. Preferably together with a consolidated index.  (And maybe `ghc --help` should give the local URL of this documentation root.)",simonpj
1,7359,43,"george.colpitts@…, ekmett@…",unix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1),libraries/unix,7.4.1,7.6.3,igloo,new,highest,2013-06-18T13:55:44-0700,"Some package I am trying to build with cabal causes cabal to try to install unix-2.6.0.0 . This fails with the following errors: 


{{{
[35 of 38] Compiling System.Posix.Signals ( dist/build/System/Posix/Signals.hs, dist/build/System/Posix/Signals.o )
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c: In function ‘ghc_wrapper_dtUw_sigismember’:

/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:8:0:
     warning: dereferencing ‘void *’ pointer

/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:8:0:
     error: void value not ignored as it ought to be
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c: In function ‘ghc_wrapper_dtUF_sigfillset’:

/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:10:0:
     warning: dereferencing ‘void *’ pointer

/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:10:0:
     error: invalid use of void expression
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c: In function ‘ghc_wrapper_dtUR_sigdelset’:

/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:12:0:
     warning: dereferencing ‘void *’ pointer

/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:12:0:
     error: invalid use of void expression
Failed to install unix-2.6.0.0
}}}

This seems to be a recent problem for me, so it may be due to some software updates for mac os x. I am running os x version 10.8.2 build 12c60.  I have XCode version 4.5.1 with the ""Command Line Tools"" installed.  I installed ghc from the haskell-platform after updating the os x and xcode (and command line tools). ",AndreasVoellmy
3,7961,43,"eir@…, adam.gundry@…",Remove restrictions on promoting GADT's,Compiler,7.6.3,,,new,normal,2013-06-17T00:49:12-0700,"(Also allow the promotion of data types whose kind is not (* -> ... -> *))

I have been using -XDataKinds lately to explore the sorts of dependently typed programming that are currently possible in GHC. I am particularly interested in DSL's and embedding other languages' type systems into Haskell so that GHC can help verify the correctness of the program fragments I construct for those languages. From my point of view as an end-user, the restrictions on what data get promoted is inconsistent and oftentimes annoying to deal with. There are two related issues on my end:

1. The restriction that a data type cannot have a kind mentioning a promoted kind means that the way I stratify my type machinery impacts whether or not GHC will promote everything as I would like.

2. The inability to use promoted GADT's forces me to encode relationships between my type building blocks in trickier ways, and sometimes I am simply unable to come up with an alternative.

I have found that these issues get in my way as a programmer of modest skill. Oftentimes I will explore a particular design but be forced to abandon it because my ""natural"" line of reasoning runs into GHC's restrictions. With sufficient cleverness you can do quite a lot of impressive stuff with the current system, but I am often not sufficiently clever nor am I equipped to determine when something is outright ''impossible''.

Lifting these restriction, from ''my'' point of view, would simplify the machinery a great deal and allow me to do type-level programming that is currently out of my reach. It would make the kind extensions more uniform and more complete to us end-users. #6024 would complete them in another way.",danharaj
3,1831,43,"alfonso.acosta@…, eir@…",reify never provides the declaration of variables,Template Haskell,6.8.1,_|_,,new,normal,2013-01-26T19:59:44-0800,"The information returned by reify when provided a variable Name is

{{{
VarI Name Type (Maybe Dec) Fixity
}}}

The Dec part, due to be nested in Maybe, is clearly optional. In fact, according to Language.Haskell.TH.Syntax:

{{{
-- Nothing for lambda-bound variables, and
-- for anything else TH can't figure out
-- E.g. [| let x = 1 in $(do { d <- reify 'x; .. }) |]
}}}

However, the typechecker (TcSplice module) always returns Nothing. So it's simply not implemented.


I suggest either implementing the feature or removing the Dec part of VarI. Either way, the type should be consistent with the features offered in TH.
",guest
4,3052,43,"lennart@…, illissius@…",ghc FFI doesn't support thiscall,Compiler (FFI),6.10.1,7.6.2,,new,low,2012-09-12T04:12:16-0700,"The ghc FFI does not support the ""thiscall"" calling convention.
This is the calling convention used by Microsoft C++ for calling methods.
It's like the stdcall calling convention, except that the ""this"" pointer is passed in ECX.

Without this calling convention it's impossible to interact with (Msft) C++ objects.
",augustss
5,344,43,"ross@…, abcz2.uprola@…",arrow notation: incorrect scope of existential dictionaries,Compiler (Type checker),6.4,7.6.2,ross,new,lowest,2013-03-04T01:43:32-0800,"{{{
ghc-6.4: panic! (the `impossible' happened, GHC version
6.4):
        cgPanic
    deref{v a1yz}
    static binds for:
    local binds for:
    SRT labelghc-6.4: panic! (the `impossible'
happened, GHC version 6.4):
        initC: srt

Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.

I've attached a test driver that can reproduce the problem.

-- Esa Pulkkinen <esa.pulkkinen@kotiposti.net>

}}}",nobody
2,7097,42,"bos@…, mikesteele81@…",linker fails to load package with binding to foreign library,Runtime System,7.4.2,7.8.1,,new,high,2013-05-01T12:40:48-0700,"GHCI is unable to load 'network' package on Windows. The versions:
{{{
$ ghci --version
The Glorious Glasgow Haskell Compilation System, version 7.4.2
}}}
{{{
$ ghc-pkg list network
c:/mnt/data1/ghc32b\lib\package.conf.d:
    network-2.3.0.14
}}}

The test code:
{{{
import Network

main = withSocketsDo $ do listenOn (PortNumber 3333) -- >>= accept
}}}

The failure:
{{{
> ghci winsock-load-failure.hs
GHCi, version 7.4.2: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main             ( winsock-crash.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
Loading package bytestring-0.9.2.1 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package text-0.11.2.2 ... linking ... done.
Loading package parsec-3.1.3 ... linking ... done.
Loading package network-2.3.0.14 ... linking ... <interactive>: C:\mnt\data1\ghc32b\network-2.3.0.14\ghc-7.4.2\HSnetwork-2.3.0.14.o: unknown symbol `__imp__WSACleanup'
ghc.exe: unable to load package `network-2.3.0.14'
}}}

The load trace log ('+RTS -Dl'):
{{{
[...snip...]
lookupSymbol: looking up __imp__WSACleanup@0
initLinker: start
initLinker: idempotent return
lookupSymbol: symbol not found
<interactive>: C:\mnt\data1\ghc32b\network-2.3.0.14\ghc-7.4.2\HSnetwork-2.3.0.14.o: unknown symbol `__imp__WSACleanup'
[...snip...]
}}}

The symbol to be resolved:
{{{
$ nm network-2.3.0.14/ghc-7.4.2/HSnetwork-2.3.0.14.o |grep WSACleanup
         U __imp__WSACleanup@0
}}}

The actual symbol in the foreign library:
{{{
$ objdump -p  /c/Windows/System32/ws2_32.dll
c:/Windows/System32/ws2_32.dll:     file format pei-i386
[...snip...]
[Ordinal/Name Pointer] Table
[...snip...]
        [ 115] WSACleanup
[...snip...]
}}}

The test snippet only works when compiled by ghc (so the resulting binary is produced by ld.bfd).",nus
4,4052,42,"vogt.adam@…, richard@…",Two sided sections,Compiler,6.12.2,7.6.2,,new,low,2012-09-12T04:12:24-0700,"Allow sections to be functions of two arguments:

{{{
( # c ## ) a b === a # c ## b
}}}

Where the associativities of ''#'' and ''##'' are then used.",aavogt
2,4144,41,"AntoineLatter, joeyadams3.14159@…",Exception: ToDo: hGetBuf - when using custom handle infrastructure,libraries/base,7.6.1,7.8.1,simonmar,patch,high,2013-06-17T13:28:57-0700,"When trying to use the custom handle infrastructure, hGetContents fails like so:

*** Exception: ToDo: hGetBuf

This exception occurs twice in GHC.IO.Handle.Text

The handle implementation I'm using is attached.

It would be neat if I could pass along some witness that my device implements RawDevice, then we could just run the same code that we use for file-descriptors. But I'd be happy enough with a general solution, as I just plan to use this for testing.",AntoineLatter
4,3372,41,"howard_b_golden@…, ezyang@…",Allow for multiple linker instances,Compiler,,7.6.2,,new,low,2013-03-06T23:03:12-0800,"Right now there is only one RTS linker with a single symbol table.This means, for example, that one cannot have multiple instances of the GHC interpreter in the same process running simultaneously.

",jcpetruzza
4,4479,41,"gideon@…, griba2001@…",Add Type Directed Name Resolution,Compiler (Type checker),7.5,7.6.2,,new,low,2012-09-12T04:12:32-0700,"A request to implement [http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution type-directed name resolution], as [http://hackage.haskell.org/trac/haskell-prime/ticket/129 proposed] for Haskell'.",gidyn
2,5954,40,"buecking@…, conrad@…",Performance regression 7.0 -> 7.2 (still in 7.4),Compiler,7.4.1,7.6.2,simonpj,new,high,2012-10-07T18:24:33-0700,"The program in `nofib/parallel/blackscholes` regressed quite badly in performance between 7.0.x and 7.2.1.  This is just sequential performance, no parallelism.

With 7.0:

{{{
   3,084,786,008 bytes allocated in the heap
       5,150,592 bytes copied during GC
      33,741,048 bytes maximum residency (7 sample(s))
       1,541,904 bytes maximum slop
              64 MB total memory in use (2 MB lost due to fragmentation)

  Generation 0:  5760 collections,     0 parallel,  0.08s,  0.08s elapsed
  Generation 1:     7 collections,     0 parallel,  0.01s,  0.01s elapsed

  INIT  time    0.00s  (  0.00s elapsed)
  MUT   time   17.43s  ( 17.47s elapsed)
  GC    time    0.09s  (  0.09s elapsed)
  EXIT  time    0.00s  (  0.00s elapsed)
  Total time   17.53s  ( 17.56s elapsed)
}}}

With 7.2.2:

{{{
   3,062,127,752 bytes allocated in the heap
       4,714,784 bytes copied during GC
      34,370,232 bytes maximum residency (7 sample(s))
       1,553,968 bytes maximum slop
              64 MB total memory in use (2 MB lost due to fragmentation)

                                    Tot time (elapsed)  Avg pause  Max pause
  Gen  0      5781 colls,     0 par    0.08s    0.08s     0.0000s    0.0006s
  Gen  1         7 colls,     0 par    0.01s    0.01s     0.0014s    0.0017s

  INIT    time    0.00s  (  0.00s elapsed)
  MUT     time   23.93s  ( 23.93s elapsed)
  GC      time    0.09s  (  0.09s elapsed)
  EXIT    time    0.00s  (  0.00s elapsed)
  Total   time   24.02s  ( 24.03s elapsed)
}}}

and with 7.4.1:

{{{
   3,061,924,144 bytes allocated in the heap
       4,733,760 bytes copied during GC
      34,210,896 bytes maximum residency (7 sample(s))
       1,552,640 bytes maximum slop
              64 MB total memory in use (2 MB lost due to fragmentation)

                                    Tot time (elapsed)  Avg pause  Max pause
  Gen  0      5781 colls,     0 par    0.08s    0.08s     0.0000s    0.0007s
  Gen  1         7 colls,     0 par    0.01s    0.01s     0.0015s    0.0017s

  INIT    time    0.00s  (  0.00s elapsed)
  MUT     time   23.90s  ( 23.91s elapsed)
  GC      time    0.09s  (  0.09s elapsed)
  EXIT    time    0.00s  (  0.00s elapsed)
  Total   time   24.00s  ( 24.00s elapsed)
}}}
",simonmar
2,7598,40,"pho@…, mle+hs@…",ghc-stage1 generates wrong assembler on StgCmmPrim (operand out of range),Compiler,7.7,7.8.1,,new,high,2013-04-14T04:03:15-0700,"Hello,
an attempt to compile today GHC HEAD on linux powerpc fails with this message
{{{
""inplace/bin/ghc-stage1"" -static  -H32m -O    -package-name ghc-7.7.20130115 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/../rts/dist/build -Icompiler/stage2 -Icompiler/. -Icompiler/parser -Icompiler/utils   -optP-DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.17.0 -package array-0.4.0.2 -package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.10.3.0 -package containers-0.5.0.0 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package hoopl-3.10.0.0 -package hpc-0.6.0.1 -package process-1.2.0.0 -package template-haskell-2.9.0.0 -package time-1.4.0.2 -package transformers-0.3.0.0 -package unix-2.6.1.0  -Wall -fno-warn-name-shadowing -XHaskell98 -XNondecreasingIndentation -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O2  -no-user-package-db -rtsopts      -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -hisuf hi -osuf  o -hcsuf hc -c compiler/codeGen/StgCmmPrim.hs -o compiler/stage2/build/StgCmmPrim.o
/tmp/ghc20445_0/ghc20445_0.s: Assembler messages:

/tmp/ghc20445_0/ghc20445_0.s:98896:0:
     Error: operand out of range (0x00000000000081ac is not between 0xffffffffffff8000 and 0x0000000000007ffc)
make[1]: *** [compiler/stage2/build/StgCmmPrim.o] Error 1
make: *** [all] Error 2
}}}
The platform is 32bit PowerPC running debian wheezy which provides GHC 7.4.1 used for bootstrapping GHC HEAD.",kgardas
3,3242,40,"felipe.lessa@…, jwlato@…",ghci: can't load .so/.DLL for: m (addDLL: could not load DLL),GHCi,7.4.1,7.6.2,,new,normal,2012-09-12T03:26:07-0700,"On Windows, when attempting to use Hipmunk from ghci, it produces the error:
{{{
ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)
}}}
To reproduce:
{{{
cabal install Hipmunk
ghci
:m + Physics.Hipmunk
initChipmunk
}}}

Presumably this has something to do with there being no libm on Windows.",jeffz1
3,5443,40,"johan.tibell@…, bos@…",Errors when shutting down the event manager loop,Compiler,7.2.1,7.6.2,tibbe,new,normal,2012-09-12T04:12:03-0700,"As explained in [http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/20573 this thread on the GHC list] I use the GHC event manager in my [https://github.com/basvandijk/usb usb library]. I create my own `EventManager` and start a thread which runs the event manager loop. When the library is finalized I automatically shutdown the loop. However this causes error messages from the RTS to be printed.

The following program shows the problem in isolation:
 
{{{
import Control.Concurrent
import GHC.Event

main = do
 em <- new
 tid <- forkIO $ loop em
 threadDelay 2000000
 shutdown em  -- Note that 'killThread tid' has the same effect.
 threadDelay 2000000
}}}

Make sure to build it with `-threaded` enabled:

`$ ghc -threaded --make eventManagerBug.hs`

Running it gives the following errors:

{{{
$ ./eventManagerBug
example: ioManagerWakeup: write: Bad file descriptor
example: ioManagerDie: write: Bad file descriptor
}}}

Note that these errors are printed in the `ioManagerWakeup` function in `rts/posix/Signals.c`.",basvandijk
3,5775,40,"pho@…, v.dijk.bas@…",Inconsistency in demand analysis,Compiler,7.5,7.6.2,,new,normal,2012-09-12T03:26:08-0700,"A small program:

{{{
{-# LANGUAGE MagicHash, UnboxedTuples #-}
module U where
import GHC.Prim
import GHC.Types

idx :: Addr# -> Int -> Int
{-# INLINE idx #-}
idx a (I# i) = case readIntOffAddr# a i realWorld# of (# _, y #) -> I# y

f :: Int -> Int -> Int
{-# INLINE f #-}
f x y = y + x

foo :: Addr# -> Int -> Int
foo a n = n `seq` loop (idx a 0) 1
  where
    loop x i = case i >= n of
      False -> loop (f x (idx a i)) (i+1)
      True  -> x
}}}

GHC infers the demand `LU(L)` for `loop`, only unboxes the second argument, ultimately generates a loop of type `Int -> Int# -> Int` and always allocates a thunk for the first argument:

{{{
      $wloop_si9 [Occ=LoopBreaker] :: Int -> Int# -> Int
      [LclId, Arity=2, Str=DmdType LL]
      $wloop_si9 =
        \ (w1_shU :: Int) (ww1_shX :: Int#) ->
          case >=# ww1_shX ww_si5 of _ {
            False ->
              $wloop_si9
                (case readIntOffAddr# @ RealWorld w_si2 ww1_shX realWorld#
                 of _ { (# _, y_a9S #) ->
                 case w1_shU of _ { I# y1_ahb -> I# (+# y_a9S y1_ahb) }
                 })
                (+# ww1_shX 1);
            True -> w1_shU
          }; }
}}}

But if I change the pragma on `f` from `INLINE` to `NOINLINE`, `loop` gets the demand `U(L)U(L)m` and GHC manages to unbox both arguments as well as the result, producing a nice tight loop:

{{{
      $wloop_sii [Occ=LoopBreaker] :: Int# -> Int# -> Int#
      [LclId, Arity=2, Str=DmdType LL]
      $wloop_sii =
        \ (ww1_shW :: Int#) (ww2_si0 :: Int#) ->
          case >=# ww2_si0 ww_sib of _ {
            False ->
              case readIntOffAddr# @ RealWorld w_si8 ww2_si0 realWorld#
              of _ { (# _, y1_Xac #) ->
              case f (I# ww1_shW) (I# y1_Xac) of _ { I# ww3_Xin ->
              $wloop_sii ww3_Xin (+# ww2_si0 1)
              }
              };
            True -> ww1_shW
          }; }
}}}

It would be nice if this happened in both cases.",rl
3,5844,40,"jameshfisher@…, eventh@…",Panic on generating Core code,External Core,7.4.1,7.6.2,,new,normal,2012-09-12T04:12:10-0700,"STEPS TO REPRODUCE

1. Create the file ""Panic.hs"" with the contents:

{{{
module Main where
main = print 1
}}}

2. Compile with ""ghc -fext-core Panic.hs""


EXPECTED BEHAVIOR

Generation of the Core file ""Panic.hcr"".


ACTUAL BEHAVIOR

{{{
$ ghc -fext-core Panic.hs
[1 of 1] Compiling Main             ( Panic.hs, Panic.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.4.1 for x86_64-unknown-linux):
	MkExternalCore died: make_lit

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

$
}}}

As it states, I am using GHC version 7.4.1 for x86_64 Linux, on an x86-64 Linux box running Ubuntu 11.10 an Linux kernel 3.0.0-14-generic.",JamesFisher
3,5927,40,"dimitris@…, shane@…","A type-level ""implies"" constraint on Constraints",Compiler (Type checker),7.4.1,7.6.2,,new,normal,2013-03-12T08:15:26-0700,"I have a datatype:

{{{
data Exists c where Exists :: c a => a -> Exists c
}}}

I have an instance for it:

{{{
instance Show (Exists Show) where
    show (Exists a) = show a
}}}

And that's alright, as far as it goes: any Exists Show can indeed itself be shown. But I want more. I want to be able to say:

{{{
instance (c `Implies` Show) => Show (Exists c) where
    show (Exists a) = show a
}}}

In other words, I want to be able to say that any (Exists c) where the constraint c implies Show can be shown. For example, if Num still had a Show constraint, I wouldn't want to have to write a separate instance Show (Exists Num) to be able to show an Exists Num; I would want to be able to write a single instance (along the lines of the above) which works for both.

GHC clearly has this information: it lets me use a function of type {{{forall a. Eq a => a -> r}}} as one of type {{{forall a. Ord a => a -> r}}}, but not vice versa, so it knows that Ord implies Eq, but not vice versa. I've attached a file which demonstrates this and a couple of other examples.

What's not completely clear to me is what would be the appropriate way to be able to ask it about this. An Implies constraint to parallel the (~) constraint would work, but with what syntax? (Just straightforwardly call it Implies?) And what semantics -- what would be the kind of Implies? It's notable that in the above example its arguments aren't of type Constraint, but rather * -> Constraint, and for (* -> *) -> Constraint it could similarly work, and with MPTCs * -> * -> Constraint and (* -> *) -> (* -> *) -> Constraint and * -> (* -> *) -> Constraint and so on probably also make sense... but I have no idea how to formalize this, where the boundaries lie, and whether it makes any kind of sense. I can try to think harder about it if that would help, but hopefully the outlines of the situation are more immediately obvious to someone on the GHC team.",illissius
3,5071,40,"dagitj@…, daniel@…",GHCi crashes on large alloca/allocaBytes requests,Compiler,7.0.3,_|_,,new,normal,2011-12-13T01:36:54-0800,"GHCi, and ghc, seems to exit (crash?) on certain types of memory allocation exceptions.

The FFI addendum says that the allocation functions should be able to return null:
http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise5.html#x8-230005

Section 5.8 says this:

> If any of the allocation functions fails, a value of Ptr.nullPtr is produced. If free or reallocBytes is applied to a memory area that has been allocated with alloca or allocaBytes, the behaviour is undefined. Any further access to memory areas allocated with alloca or allocaBytes, after the computation that was passed to the allocation function has terminated, leads to undefined behaviour. Any further access to the memory area referenced by a pointer passed to realloc, reallocBytes, or free entails undefined behaviour.


In practice, code examples and documentation appear to rely on `alloca` '''NOT''' returning a `nullPtr`:
 * http://en.wikibooks.org/wiki/Haskell/FFI
 * http://www.haskell.org/haskellwiki/HSFFIG/Examples
 * http://book.realworldhaskell.org/read/interfacing-with-c-the-ffi.html

I reported this on the libraries list, and offered a documentation tweak, and I was asked to create a ticket:
http://www.haskell.org/pipermail/libraries/2011-March/016117.html

That email has details about the testing I did at the time to see the crashing behavior in ghci. I was using ghc 7.0.2 on 64bit windows, but this also appears to affect 7.0.3 on linux.  It's likely that other versions of ghc are affected.

My recommendation would be to make the exception thrown by `alloca` catchable.  Possibly offering an alternative to `alloca`, say `alloca'`, that can produce a `nullPtr` instead of using exceptions.  I would advice against changing the existing `alloca` function to produce `nullPtr` as that could make a lot of existing code unsafe.

For example, it would be nice if the following printed ""exception"", instead of exiting:
{{{
$ ulimit -d 100000 -m 1000000 -v 100000
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.3
$ ./Alloca 
Alloca: out of memory (requested 2148532224 bytes)
$ cat Alloca.hs
import Foreign
import Foreign.Marshal
import Foreign.Marshal.Alloc
import GHC.Exception
import System.IO.Error

main :: IO ()
main = do
  (allocaBytes maxBound compare)
    `catch` (\_ -> print ""exception"")
  where
  compare p = print ((nullPtr :: Ptr Int) == p)
}}}",guest
3,284,40,"sven.panne@…, bos@…",RPM doesn't support --prefix,Build System,None,_|_,juhp,new,normal,2009-11-18T03:42:17-0800,"{{{
After installing ghc for linux using rpm with
--prefix=/usr/local,
the ghc scriipt incorrectly thinks the libraries etc
are in /usr:

#!/bin/sh
GHCBIN=""/usr/lib/ghc-6.2.2/ghc-6.2.2"";
TOPDIROPT=""-B/usr/lib/ghc-6.2.2"";
# Mini-driver for GHC
exec $GHCBIN $TOPDIROPT ${1+""$@""}

After editing, at least the compiler actually starts up :)

}}}",skaller
5,2598,40,"ndmitchell@…, rl@…",Avoid excessive specialisation in SpecConstr,Compiler,6.8.3,7.6.2,,new,lowest,2013-03-07T08:51:46-0800,"This ticket captures an email thread so it doesn't get lost. 

Consider this (from `haddock/src/Haddock/Backends/Hoogle.hs`):
{{{
dropComment (' ':'-':'-':' ':_) = []
dropComment (x:xs) = x : dropComment xs
dropComment [] = []
}}}
This desugars thus:
{{{
dropComment xs
  = case xs of
      (C# x1 : xs1) ->
        case x1 of
          ' '# ->
             case xs1 of
               (C# x2:xs2) ->
                 case x2 of
                   '-' -> ....
                   DEFAULT -> dropComment (C# x2 : xs2)
          DEFAULT -> ...
       [] -> ...
}}}
I have elided the branches that are less interesting, and I have done a bit of multi-level pattern matching to save space.

The thing to notice is this: at the recursive call, we know that the argument is a cons, with C# at the front.  So `SpecConstr` dutifully creates a specialized version.  And similarly for ''each subsequent character''!  Indeed, if the match fails after matching `(' ': '-' : )` prefix, the recursive call even knows that the first char is `'-'`!

Hence we get as many specializations as we have characters in the input match.

So `SpecConstr` is behaving as expected.   Can anyone think of a heuristic to squash this behavior?  At the moment we take the first N specializations and then stop.  One heuristic might be ""if there are lots of recursive calls, don't specialize"".  But that is very close to ""if there are lots of specializations, drop some"".   Mind you, perhaps we should be more vigorous still: ""if there are more than N, don't do any"" on the grounds that randomly choosing the first few is unlikely to be useful.

Any thoughts?

",simonpj
5,2641,40,"koen@…, lennart@…",Revise the rules for -XExtendedDeafultRules,Compiler,6.8.3,7.6.2,,new,lowest,2012-09-12T04:14:02-0700,"The `-XExtendedDefaultRules` flag is very liberal about type-class defaults. Perhaps too liberal:
{{{
> *Main> quickCheck (\xs -> reverse xs == xs)
> +++ OK, passed 100 tests.
}}}
Not good (reverse on lists is not the identity function). I expect a type error!  Reason: reverse on list of () is indeed the identity function!

[http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluation.html#extended-default-rules The rules] are currently these:
 * All of the classes Ci are single-parameter type classes.
 * At least one of the classes Ci is numeric, or is Show, Eq, or Ord. 

Maybe we should tighten up the second rule to say: 
 * '''All''' of the classes Ci is numeric, or is Show, Eq, or Ord. 
Then the Quickcheck example would not bogusly succeed in typechecking, because there's an `Arbitrary` constraint involved.

This ticket is to record the idea and canvas opinion.  Record thoughts below.

See also 
 * #2853
 * #2854",simonpj
3,368,39,"pho@…, marco-oweber@…",Provide a Java Backend,Compiler,None,_|_,,new,normal,2010-07-19T09:39:57-0700,"{{{
I hope the GHC provide a JVM backend.

also:
1. GHC compile hs to bytecode(name as klass) like what
javac
and klass can be packed as kjar(like jar in java)

2. an KVM interpret the klass bytecode and translate it
to java .class, then execute it on JVM. the KVM can be
write in haskell also.

now, a pure java based GHC and KVM can be used on JVM like
1. ghc.kjar contains the ghc compiler
2. happy.kjar contains the happy compiler
3. kvm.kjar contains the KVM
4. kvm.jar contains the bootstrap kvm that can be run
on JVM.


}}}",rainbowang
4,3625,39,"pho@…, anton.nik@…",GHCI doesn't work with dtrace on OS X,GHCi,6.10.4,7.6.2,,new,low,2012-09-12T04:12:18-0700,"On OS X, user-defined dtrace probes are implemented as special symbols of the form `___dtrace_probe$...` which are magically resolved by the linker. In the attached package, we have this dtrace script:

{{{
provider haskell {
  probe demo__trace(char*);
};
}}}

and this C file:

{{{
void demo_trace( char *s )
{
  HASKELL_DEMO_TRACE(s);
}
}}}

When we compile it, we get:

{{{
newbie:dtrace-demo rl$ nm demo-trace.o
         U ___dtrace_probe$haskell$demo__trace$v1$63686172202a
         U ___dtrace_stability$haskell$v1$1_1_0_1_1_0_1_1_0_1_1_0_1_1_0
         U ___dtrace_typedefs$haskell$v1
00000000 T _demo_trace
}}}

When linked as a dynamic library, the undefined symbols disappear:

{{{
newbie:dtrace-demo rl$ ld -dylib -o demo-trace.dylib demo-trace.o 
newbie:dtrace-demo rl$ nm demo-trace.dylib 
00000000 t __mh_dylib_header
000008b0 T _demo_trace
}}}

But GHCI's linker can't resolve the symbols which means that GHCI will fail if it tries to load demo-trace.o or a package file that contains demo-trace.o. For the attached package, `ghci -package dtrace-demo` produces this error:

{{{
unknown symbol `___dtrace_probe$haskell$demo__trace$v1$63686172202a'
Loading package dtrace-demo-1.0 ... linking ... ghc: unable to load package `dtrace-demo-1.0'
}}}

Unless I'm mistaken, the only solution is to use dlopen instead of a hand-written linker as the dtrace symbols are actually resolved by the kernel.

The problem came up while implementing dtrace-based profiling for DPH. DPH uses Template Haskell so GHC tries to load a package which uses dtrace and dies.",rl
4,3701,39,"illissius@…, pho@…",allow existential wrapper newtypes,Compiler,6.10.4,7.6.2,,new,low,2012-09-12T04:12:19-0700,"Consider this OO-style thing, a class Compiler, and a most general instance MkCompiler:
{{{
class Compiler c where
  getInstalledPackages :: c -> IO [String]

data GHC = GHC { }
data NHC = NHC { }

ghc :: GHC
ghc = GHC { }

nhc :: NHC
nhc = NHC { }

instance Compiler GHC
instance Compiler NHC

data MkCompiler where
  MkCompiler :: Compiler c => c -> MkCompiler

instance Compiler MkCompiler where
  getInstalledPackages (MkCompiler c) = getInstalledPackages c

compilers :: [MkCompiler]
compilers = [MkCompiler ghc, MkCompiler nhc]
}}}

There's two language features we want to make this really nice:

 1. Letting us call the data type `Compiler` rather than `MkCompiler`. That would mean separating the class and type namespaces.
 2. Letting us derive the Compiler instance for `MkCompiler`.

For the latter we would want either:
{{{
newtype MkCompiler where
    MkCompiler :: Compiler c => c -> MkCompiler
  deriving Compiler
}}}
or
{{{
data MkCompiler where
    MkCompiler :: Compiler c => c -> MkCompiler
  deriving Compiler
}}}

The advantage of the first is that newtype deriving already exists as a concept so that's nice and consistent. The problem is we do not allow newtypes that use existentials. From an implementation point of view, it's clear that the representations cannot be equal because of the need to store the class dictionary. From a semantic point of view however it's not obvious that existentials with class contexts are illegitimate in newtypes. The underlying implementation would of course have to be an extra layer of boxing, so like data but with the pattern match behaviour newtype.",duncan
4,345,39,kyrab@…,GADT - fundep interaction,Compiler (Type checker),6.4,_|_,simonpj,new,low,2009-11-19T04:53:27-0800,"{{{
GADTs and fundeps don't seem to interact in the way
that I (perhaps naively) expect. I expected that for
each case, the type variables would be instantiated
according to the type of the constructors, and then the
fundep would be used to figure out the result type. 

{-# OPTIONS_GHC -fglasgow-exts #-}

data Succ n
data Zero

class Plus x y z | x y -> z
instance Plus Zero x x
instance Plus x y z => Plus (Succ x) y (Succ z)

infixr 5 :::

data List :: * -> * -> * where
              Nil :: List a Zero
              (:::) :: a -> List a n -> List a (Succ n)

append :: Plus x y z => List a x -> List a y -> List a z
append Nil ys = ys
append (x ::: xs) ys = x ::: append xs ys

{-
  GHC 6.4 says:

    Couldn't match the rigid variable `y' against `Succ z'
      `y' is bound by the type signature for `append'
      Expected type: List a y
      Inferred type: List a (Succ z)
    In the expression: x ::: (append xs ys)
    In the definition of `append': append (x ::: xs) ys
= x ::: (append xs ys)
-}
}}}",bring
4,1593,39,"tomasz.zielonka@…, marig1@…",Improve runInteractiveProcess error message when working directory does not exist,libraries/process,6.7,_|_,simonmar,new,low,2013-01-27T11:42:36-0800,"Example code:

{{{
  import System.Process

  main = do
      (_, _, _, commhand) <-
          runInteractiveProcess ""echo"" [""something""] (Just ""/no/such/dir"") Nothing
      exitCode <- waitForProcess commhand
      print exitCode
}}}

This happens on Linux with both 6.6 and the latest HEAD snapshot.

I think the problem is in C code, in libraries/base/cbits/runProcess.c (6.6).
Below are the important code fragments. Search for BUG HERE for a bug location.

{{{
ProcHandle
runInteractiveProcess (char *const args[],
               char *workingDirectory, char **environment,
               int *pfdStdInput, int *pfdStdOutput, int *pfdStdError)
{
    ...

    switch(pid = fork())
    {
    ...

    case 0:
    {
        pPrPr_disableITimers();

        if (workingDirectory) {
            if (chdir (workingDirectory) < 0) {
                // BUG HERE:
                // Calling return here is bad idea here. This code
                // is run in the child process and returning makes the
                // child act as if it was the parent - strange things will
                // happen!
                return -1;
            }
        }

        ...

        /* the child */
        if (environment) {
            execvpe(args[0], args, environment);
        } else {
            execvp(args[0], args);
        }
    }
    _exit(127);

    default:
    ...
}}}

I thought about sending a patch, but I'm not sure what the fix should be. Doing ""_exit(SOMETHING)"" instead of return seems to be better then returning, but I don't know what SOMETHING should be, and maybe there is a better solution.

I think I've seen the same problem in another run*Process function in this C file.",tomasz.zielonka@…
3,3217,38,"YitzGale, dterei, mle+hs@…",Make GHCi have separate flags for interactive Haskell expressions,Compiler,6.10.2,7.6.2,,new,normal,2012-09-12T04:11:57-0700,"It's becoming clear that in GHCi we want to have a separate set of command-line flags for
  * Compiling Haskell expressions typed at the GHCi prompt
  * Compiling entire modules, eg via `:load`
Examples of this need are:
  * We already have an ad-hoc difference in the way that type-class defaults are applied: http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluation.html#extended-default-rules
  * In #3202 there's a well-argued request to change behaviour of the monomorphism restriction

So the new feature would consist of:
 * The `InteractiveContext` should contain a set of `DynFlags` used for compiling command-line Haskell expressions (the ''interactive `DynFlags`'')
 * The `:set` command would change both the `DynFlags` maintained by GHCi for compiling entire modules (the ''batch `DynFlags`''), and the interactive `DynFlags`.
 * A new `:seti` command to change the interactive flags
 * Just possibly a `:setb` command to set the batch flags but leave the interactive ones unchanged.

Arguably it'd be good to have a command to display the current flag settings (of either `DynFlags`) but that's another blob of work.",simonpj
3,7621,38,"nathan.huesken@…, 0@…",Cross-build for QNX ARM smashes stack when using FunPtr wrappers,Compiler (FFI),7.7,7.8.1,,new,normal,2013-03-24T15:30:07-0700,"I have built an unregistered LLVM cross-compiler for arm-unknown-nto-qnx8.0.0eabi, which I finally got to build using the attached patch.  Simple programs no longer crash like they do in registered ARM cross-compilers (as reported on mailing list at http://www.haskell.org/pipermail/ghc-devs/2013-January/000005.html and other places), however the following code does crash:

{{{
{-# LANGUAGE ForeignFunctionInterface #-}
module Main (main) where

import Foreign.Ptr

foreign import ccall ""wrapper"" wrap_refresh :: ( IO ()) -> IO (FunPtr ( IO ()))

main :: IO ()
main = do
	wrap_refresh (return ())
	return ()
}}}

It seems, from experiments, that any code using the ""wrapper"" imports causes this error:

{{{
$ ./Main
*** stack smashing detected ***: Main terminated
Abort (core dumped)
}}}",singpolyma
3,7253,38,"roma@…, patrick@…",Top-level bindings in ghci,GHCi,7.6.1,7.8.1,,new,normal,2012-10-14T20:15:29-0700,"ghci now supports most of the declarations. However, it doesn't support the most basic and common type of declaraion — pattern and function bindings!

E.g.

{{{
Prelude> a = 1

<interactive>:2:3: parse error on input `='
}}}

I realise that, if implemented, they would have somewhat different semantics than in Haskell modules — e.g. with respect to recursion.

But even if they behaved in the same way as top-level monadic let-bindings, they would still be very useful for two reasons:

1. If you're doing quick experiments in ghci, ""let a=1"" is more than twice as long as ""a=1"", and that makes a difference.

2. Novices are often confused when they are told that they have to use one syntax for definitions in modules and another in ghci.
",Feuerbach
3,7285,38,"tkn.akio@…, idhameed@…",mkWeakMVar is non-compositional,Compiler,7.6.1,7.8.1,,new,normal,2013-03-11T05:10:32-0700,"In base 4.6 `addMVarFinalizer` is deprecated in favour of `mkWeakMVar` of type

{{{
    mkWeakMVar :: MVar a -> IO () -> IO (Weak (MVar a))
}}}

This type makes it inherently non-compositional. For instance, if we have a larger datatype T that contains an MVar somewhere inside then there in no way to define mkWeakT in terms of mkWeakMVar; instead, mkWeakT would have to be defined along the lines of

{{{
    mkWeakT :: T a -> IO () -> IO (Weak (T a))
    mkWeakT m@(MkT (MVar m#) _) f = IO $ \s ->
      case mkWeak# m# m f s of (# s1, w #) -> (# s1, Weak w #)
}}}

It would be better if the type of mkWeakMVar would change to

{{{
    mkWeakMVar :: MVar a -> v -> Maybe (IO ()) -> IO (Weak v)
}}}

(i.e., following `mkWeak` rather than `mkWeakPtr`). 

(The same comment goes for related functions such as mkWeakIORef.)",edsko
3,7662,38,"jwlato@…, ikke+ghc@…",Improve GC of mutable objects,Runtime System,7.7,_|_,,new,normal,2013-04-23T08:34:17-0700,"Haskell is a purely functional language at its core, but it can be also used for workloads involving mutation; it is for these workloads that our GC can be pretty poorly tuned (historically, we’ve fixed these issues case-by-case when they were causing problems for users, e.g. #650). Fortunately, the question of generational garbage collection in the face of lots of mutability is a well-studied one (c.f. the JVM) so this bug asks whether or not we can systematically appropriate any of the machinery developed here for GHC.  Some ideas include:

 * Utilizing card marking at the page level for write barriers, instead of our current mutable lists,

 * Separating mutable and immutable (and lazy) data on the heaps, to make the previous scheme more likely to work well,

 * Organizing our generations in different pages, so that checking the generation of any object is as simple as a pointer comparison,

 * Figure out if we can do better than permanently keeping all mutable arrays permanently on the mutable list (which is really killer when you have lots of tiny mutable arrays),

 * More mutable closure types to remove the indirection that would normally result from an IORef (actually, you can UNPACK these, and I’m not 100% what happens in that case; it depends on how MutVar#s are represented)

There’s probably more things but this is just a start to get things rolling. Test cases and benchmarks also appreciated!",ezyang
4,5333,38,"peteg42@…, ross@…",Arrow command combinators and infixr cause the desugarer to fail,Compiler (Parser),7.0.3,7.6.2,ross,new,low,2013-03-04T01:50:00-0800,"The following code exhibits the bug:

{{{
{-# LANGUAGE Arrows, NoMonomorphismRestriction #-}
module T where

import Prelude hiding ( id, (.) )
import Control.Arrow

cc1 :: Arrow a => a e b -> a e b -> a e b
cc1 = undefined

-- 'g' fails to compile.
-- g = proc (x, y, z) ->
--   ((returnA -< x) &&& (returnA -< y) &&& (returnA -< z))

-- 'f' compiles:
--   - without an infix declaration
--   - with the infixl declaration
-- and fails with the infixr declaration
infixr 6 `cc1`
-- infixl 6 `cc1`

f = proc (x, y, z) ->
  ((returnA -< x) `cc1` (returnA -< y) `cc1` (returnA -< z))

}}}

GHC says:

{{{
ghc: panic! (the 'impossible' happened)
  (GHC version 7.0.3 for i386-apple-darwin):
	dsSyntaxTable Not found: base:GHC.Desugar.>>>{v 01W}
}}}
",peteg
4,4001,38,"ezyang@…, leon.p.smith@…",Implement an atomic readMVar,Runtime System,6.12.2,7.6.2,ezyang,new,low,2013-06-15T07:45:56-0700,"Requested by various people, most recently by John Launchbury.

The idea would be that `readMVar` is atomic, and never blocks if the `MVar` is full.  A concurrent `putMVar` operation cannot intervene while `readMVar` is reading the value.

To implement this, we would need two kinds of blocked threads in the `MVar` queue, and `putMVar` would need to wake up zero or more `readMVar` operations followed by at most one `takeMVar`.",simonmar
5,2530,38,"leather@…, ndmitchell@…",deriving Show adds extra parens for constructor with record syntax,Compiler,6.8.3,7.6.2,,new,lowest,2013-02-17T12:55:42-0800,"Since record construction binds more tightly than function application, no parentheses are needed when passing a constructor with record syntax to a function constructor. As a result, we can pass {{{Just A {x = 5}}}} as shown below.

{{{
module Main where

data A = A {x :: Int} deriving (Show)

main :: IO ()
main = print $ Just A {x = 5}
}}}

But we get the result in the GHCi session below:

{{{
*Main> main
Just (A {x = 5})
}}}

I tried looking through {{{TcGenDeriv}}}, but didn't figure out quite where the parenifying was done. {{{nested_compose_Expr}}}? {{{show_thingies}}}?

I just wanted to make a ticket for general knowledge. Of course, this is not a real bug. Perhaps you could reclassify it as a feature. Either way, it would be nice to have.",spl
5,2867,38,"ndmitchell@…, lemmih@…","Make a way to tell GHC that a pragma name should be ""recognised""",Compiler,6.10.1,7.6.2,,new,lowest,2012-09-12T04:14:05-0700,"GHC warns about unrecognised pragmas, but other impls can add pragmas inbetween GHC releases. If you want to use those pragmas then you can't just use `-Wall -Werror` when compiling. We could make a pragma to tell GHC to not warn about other pragmas, e.g.
{{{
{-# KNOWN_PRAGMA FOO #-}
}}}
would make GHC not warn about `FOO` pragmas.

Suggested in #2847.
",igloo
3,703,37,"duncan.coutts@…, fpishard",all binaries built by ghc have executable stacks,Compiler (NCG),7.6.3,6.6.1,,new,normal,2013-06-13T21:01:32-0700,"= Non-executable stacks =
The GNU toolchain supports marking object files that do not need to use an executable stack. Currently all object files produced by GHC lack these notes and so the linker defaults to using an executable stack for the resulting binary.

This makes some people grumpy. In particular it makes the Gentoo QA people grumpy. :-)

'''The long story''':
http://www.gentoo.org/proj/en/hardened/gnu-stack.xml

'''The quick story''':
Every .S file produced by ghc should include:
{{{
.section .note.GNU-stack,"""",@progbits
}}}

Currently this does not happen for either -fasm or -fvia-C.

== For -fasm ==
ghc simply does not emit the .section .note.GNU-stack stuff into the assembly output.

== For -fvia-C ==
ghc emits C which is then compiled by gcc. The resulting .raw_s file does
contain the .section .note.GNU-stack. However ghc then runs the generated assembly through the ""evil mangler"" which doesn't grok the .section
.note.GNU-stack and does not emit it to the final assembly file.

So the solution is to get ghc to emit the .note.GNU-stack in it's native code geneerator and to modify the evil mangler to pass the .note.GNU-stack through to the output.

We may still have a problem with the ""split objs"" feature (which ghc uses for its own libraries). Hopefully it'd just be a matter of adding .note.GNU-stack to each .s file that is spat out by ghc -split-objs.

----

For reference see http://bugs.gentoo.org/show_bug.cgi?id=123698",duncan
3,7243,37,"gostrc@…, malaquias@…",regression: acceptable foreign result types,Compiler (FFI),7.6.1,7.6.2,igloo,new,normal,2012-09-18T01:47:50-0700,"The following short file is rejected:

{{{
import Foreign.Ptr
foreign import ccall ""wrapper"" foo :: IO (FunPtr ())
}}}

The error is:

{{{
test.hs:2:1:
    Unacceptable type in foreign declaration: IO (FunPtr ())
    When checking declaration:
      foreign import ccall safe ""wrapper"" foo :: IO (FunPtr ())
}}}

However, my reading of the 2010 Report suggests this should be acceptable. Specifically:

* Prelude.IO t is a marshallable foreign result type when t is a marshallable foreign type,[[BR]]
* all basic foreign types are marshallable foreign types, and[[BR]]
* FunPtr a is a basic foreign type for all a.

(Political note: I include this chain of reasoning not because I think others too stupid to recreate it, but because I think it likely that I am not reading the Report correctly, and want to make it easy to detect and correct any misconceptions I have.)",dmwit
3,427,37,"dons@…, rturk@…",Random.StdGen slowness,libraries/random,,_|_,rrnewton,new,normal,2013-04-06T13:58:13-0700,"{{{
Two (performance) problems in one:

{-# OPTIONS -fffi #-}
module Main (main) where

import Control.Monad
import Random

foreign import ccall unsafe ""random"" _crandom :: IO Int

randomInt :: (Int, Int) -> IO Int
randomInt (min,max) = do
    n <- _crandom
    return $ min + n `rem` range
    where
        range = max - min + 1

main = replicateM_ (5*10^6) $ do
    x <- randomRIO (0::Int,1000) :: IO Int
    x `seq` return ()
    return ()

First, without the ""seq"" at the end, hardly anything is
evaluated and we're building huge amounts of thunks.
Three ideas about this one:
- Blame the user :)
- data StdGen = StdGen !Int !Int
  Use strict fields in StdGen. Doesn't actually help
(at least in this example).
- Force evaluation of the StdGen in getStdRandom.
  Does help in this example, but also changes behaviour
of the library:
  x <- randomRIO undefined
  currently dies only when x (or the result of a later
randomRIO) is evaluated. This change causes it to die
immediately.

Second, even _with_ the ""seq"", replacing ""randomRIO"" by
""randomInt"" speeds the thing up with a factor of about
30. (2 to 3.6, in a ""real world"" university practicum
exercise of 900 lines of code)
Even given the fact that they're not really doing the
same thing, this seems rather much :(
}}}",remit
3,6065,37,"zep_haskell_trac@…, rpglover64",Suggested type signature causes a type error (even though it appears correct),Compiler (Type checker),7.4.1,_|_,,new,normal,2012-06-05T06:12:36-0700,"The attached file, MWE.hs, contains an experiment attempting a rudimentary encoding of extensible ASTs in Haskell (without using compdata or a similar package relying upon OverlappingInstances and so forth).  The definition of the upcast function appears to be correct.  Compiling without a type signature produces a warning and the suggestion to include a type signature.  Including the suggested type signature (which appears to be the correct one) causes a type error.",tvynr
3,1371,37,"dterei, hackage.haskell.org@…",Add  -O3,Compiler,6.6.1,_|_,,new,normal,2013-03-25T04:19:02-0700,"It has been suggested that we should have an -O3 that trades off code size for speed.  Things that we could do include bumping the threshold for some optimisations (inlining, SpecConstr, LiberateCase), and perhaps inlining some operations in the back-end.

Of course we should measure the effect of various settings on nofib/nobench and pick a good combination.",simonmar
4,4135,37,"jwlato@…, acfoltzer@…",Can't Quote Instance Associated Types in Template Haskell,Template Haskell,6.12.1,7.6.2,,new,low,2012-09-12T04:12:25-0700,"Give this a whirl:
{{{
{-# LANGUAGE TypeFamilies,TemplateHaskell #-}
module Bug where

    class C a where
        type T a

    $([d|  
        instance C (Maybe a) where
            type T (Maybe a) = Char
        |])
}}}

{{{
$ ghc -c Bug.hs 
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Loading package array-0.3.0.0 ... linking ... done.
Loading package containers-0.3.0.0 ... linking ... done.
Loading package pretty-1.0.1.1 ... linking ... done.
Loading package template-haskell ... linking ... done.

Bug.hs:7:6:
    Type indexes must match class instance head
    Found `Maybe a[aMy]' but expected `Maybe a[aMx]'
    In the associated type instance for `T'
    In the instance declaration for `C (Maybe a[aMx])'
[glastonbury:~/Projects/Haskell/Truth/Core]$ 
}}}",Ashley Yakeley
4,4836,37,"dagitj@…, jmg@…",literate markdown not handled correctly by unlit,Compiler,7.0.1,7.6.2,,new,low,2012-09-12T04:13:23-0700,"This simple program in literate haskell, using markdown in the comments gives unlit problems:
{{{
### Ok so lets try this again.

### A page that loads and compiles:

> myfact 0 = 1  
> myfact n = n * n-1

Lets see if it works!
}}}

If I run unlit and collect the output I can see where it went wrong:
{{{
$ ~/lib/ghc-7.0.1/unlit Main.lhs Main.lpp
$ cat Main.lpp
### Ok so lets try this again.

### A page that loads and compiles:

  myfact 0 = 1  
  myfact n = n * n-1


}}}

When I look through the source code of unlit.c I think the place to check for this would be here:
{{{
    if ( c == '#' ) {
      if ( ignore_shebang ) {
         c1 = egetc(istream);
         if ( c1 == '!' ) {
           while (c=egetc(istream), !isLineTerm(c)) ;
           return SHEBANG;
         }
         myputc(c, ostream);
         c=c1;
      }
      if ( leavecpp ) {
        myputc(c, ostream);
        while (c=egetc(istream), !isLineTerm(c))
            myputc(c,ostream);
        myputc('\n',ostream);
        return HASH;
      }
    }
}}}

It seems that cabal has a similar unlit function:
http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal-1.10.0.0/src/Distribution-Simple-PreProcess-Unlit.html#unlit

I haven't tested it but, I think the cabal version would handle this case correctly (or be easier to fix than a C program from 1990).  Would it be possible/wise/feasible to extract the cabal version and make it a permanent replacement for the current unlit.c code?",guest
4,5014,37,"dterei, the.dead.shall.rise@…",canonicalizePath throws exception on paths that do not exist,libraries/directory,7.0.2,7.6.2,,new,low,2013-04-25T03:58:38-0700,"Assume path `foo` exists, but `foo/bar` doesn't. On GHC 6.12, `canonicalizePath ""foo/bar""` gave back a result. On GHC 7.02, I get an exception:

{{{
*** Exception: foo/bar: canonicalizePath: does not exist (No such file or directory)
}}}

The behavior is not defined by the documentation, or at all (see #4215) but it would be nice if it didn't crash.",hesselink
5,1377,37,"phercek@…, mnislaih@…",GHCi debugger tasks,GHCi,6.7,7.6.2,mnislaih,new,lowest,2013-01-21T19:17:00-0800,"I'm collecting all these together into one ticket for now.  Later we might split off individual tasks.  Please update the description if you complete one of these.

== easy ==

 * Autocompletion for :break only provides names, not modules

== moderate ==

 * for each breakpoint we should retain the declpath constructed by the coverage pass.  This would let us
   show the enclosing binding(s) for each breakpoint in the UI (eg. ""Stopped in M.f (M.hs:40:23-28)"").

 * :force should catch exceptions, so [1,2,undefined]  would display as `[1,2,< exception >]`

 * show variables with unboxed types.

 * tabs go wrong with :list (but only for .lhs files, because unlit does tab expansion... duh)

== unknown, or require thinking about ==

 * Some kind of ""step over"" or ""next"" command is needed.

 * `:break <qualified name>` only works if the name is exported can/should we relax this?

 * perhaps we should have a :watch command, that could be used to save variables for future inspection (they wouldn't get
   thrown away by :continue)

 * We can disable a breakpoint with "":set stop N :continue"", but this still prints out the breakpoint info when we stop.
   Should we print the info only if there were no commands?

 * Revert to adding tick information to the BCO directly, and remove the byte code instructions for breaks. I'm not sure that this is worth it. In some ways the implementation based on a byte code instruction is a little cleaner than adding breaks on BCOs directly. Though the bc instruction method may be a little slower than the other way.

 * Flag to disable breakpoints?

 * When we restore the interactive context on resume, we throw away any new bindings made since the breakpoint.  Can this
   be fixed?

 * threads and breakpoints.

 * if a :force results in a breakpoint, we should treat it as we do other evaluations. (currently we get
   ""*** Ignoring breakpoint"").
 
 * It's a bit strange that in ""f = e"" you don't get a breakpoint covering the whole binding, but in ""f x = e"" you do.",simonmar
2,7814,36,"ggreif@…, pho@…",panic in PPC NCG,Compiler,7.7,7.8.1,heisenbug,new,high,2013-05-10T13:25:03-0700,"I get panics in the NCG PPC register allocator while compiling these files:
{{{
  rts_dist_HC rts/dist/build/StgStdThunks.dyn_o
  rts_dist_HC rts/dist/build/StgStdThunks.thr_dyn_o
  rts_dist_HC rts/dist/build/StgStdThunks.l_dyn_o
  rts_dist_HC rts/dist/build/StgStdThunks.thr_l_dyn_o
  HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Classes.o
  HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/CString.o
  HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Debug.o
}}}
The panic message is like this:
{{{
ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 7.7.20130405 for powerpc-montavista-linux):
        allocateRegsAndSpill: Cannot read from uninitialized register
    %vI_nff

}}}

This makes the bootstapping of PPC cross compiler, ehm, delicate.

There is a comment in compiler/nativeGen/RegAlloc/Linear/Main.hs:756
{{{
                Nothing | reading   ->
                   pprPanic ""allocateRegsAndSpill: Cannot read from uninitialized register"" (ppr r)
                   -- NOTE: if the input to the NCG contains some
                   -- unreachable blocks with junk code, this panic
                   -- might be triggered.  Make sure you only feed
                   -- sensible code into the NCG.  In CmmPipeline we
                   -- call removeUnreachableBlocks at the end for this
                   -- reason.
}}}
So we have a 'junk code' issue here.

Any hints how I can debug this?",heisenbug
3,1974,36,lennart.augustsson@…,"length ""foo"" doesn't work with -XOverloadedStrings",Compiler,6.8.1,_|_,,new,normal,2012-09-06T18:49:42-0700,"The extensions to the defaulting rule for -XOverloadedStrings aren't sufficient to make {{{length ""foo""}}} typecheck without an annotation. The reason is that we end up with a constraint {{{IsString [a]}}}, and we would somehow have to decide to instantiate a to Char to get the hoped-for behaviour.

It would be nice if this could be made to work (perhaps just with -XExtendedDefaultRules), if a solution can be found without too much hacking.",ganesh
4,589,36,ganesh.sittampalam@…,Various poor type error messages,Compiler (Type checker),6.4.1,_|_,,new,low,2010-01-02T12:23:55-0800,"Hello,

I read the summary of the survey and noticed you wanted feedback on
where error messages could be improved. I looked up some (simple)
examples of type errors and ran them through ghc. I do not make any
claims to be an HCI expert, just a mere mortal with an opinion.

'''Type error 1'''

Code:
{{{
1 module Test2 where
2
3 fib n = if (3 > n) then 1 else (fib (n - 1) + fib (n - 2))
4 k = fib 's'
}}}
Error message:
{{{
Test2.hs:4:
    No instance for (Num Char)
      arising from use of `fib' at Test2.hs:4
    In the definition of `k': k = fib 's'
}}}

This isn't a bad error message in my humble opinion, it does pinpoint
that I'm doing something wrong in line 4, and that there isn't an
instance for Num Char doesn't come as a surprise. However I think it
could have been more helpful by telling me that I tried to pass a Char
to a function which expected an (Ord a, Num a) => a as its parameter.

'''Type error 2'''

Code:
{{{
1 module Test4 where
2 
3 k :: Int -> Int
4 k l = 2.0*l
}}}
Error message:
{{{
Test4.hs:4:
    No instance for (Fractional Int)
      arising from the literal `2.0' at Test4.hs:4
    In the first argument of `(*)', namely `2.0'
    In the definition of `k': k l = 2.0 * l
}}}
One reason this kind of error could happen is an inexperienced user
declaring the wrong type for his function, or not knowing that 2.0
would be interpreted as a Fractional.

'''Type error 3'''

Code:
{{{
1 module Test7 where
2
3 len' xs = head (xs) + (length xs)
4 o = len' ""GH""
}}}
Error message:
{{{
Test7.hs:4:
    Couldn't match `Int' against `Char'
        Expected type: [Int]
        Inferred type: [Char]
    In the first argument of `len'', namely `""GH""'
    In the definition of `o': o = len' ""GH""
}}}
I ran this through Hugs version November 2002 and got this error
message:
{{{
ERROR ""Test7.hs"":4 - Type error in application
*** Expression     : len' ""GH""
*** Term           : ""GH""
*** Type           : String
*** Does not match : [Int]
}}}
I find the Hugs message more clear, but that might be my background.

'''Type error 4'''

Code:
{{{
1 module Test8 where
2
3 f = head 3
}}}
Error message:
{{{
Test8.hs:3:
    No instance for (Num [a])
      arising from the literal `3' at Test8.hs:3
    Possible cause: the monomorphism restriction applied to the following:
      f :: a (bound at Test8.hs:3)
    Probable fix: give these definition(s) an explicit type signature
    In the first argument of `head', namely `3'
    In the definition of `f': f = head 3
}}}
This one I find outright scary. For ""wrong = div 3 8 + 1/2"" it gives
an error message that somewhat helps me guess the error, but the above
doesn't even come close to helping me.

/ Peter
",Peter A Jonsson [pj@…
2,3103,35,"lemmih@…, trevor@…",Compiling base with cabal fails.,Compiler,6.10.1,7.8.1,,new,high,2013-01-21T07:26:13-0800,"Compiling base with -fext-core fails with ghc-6.10.1 and ghc-6.10.1rc.

Reproduce with: cd libraries/base/ && cabal build -v --ghc-options=""-fext-core""

I've attached the output from my machine.",Lemmih
3,7048,35,"la@…, iavor.diatchki@…",Add the ability to statically define a `FunPtr` to a haskell function,Compiler,7.4.2,7.8.1,,new,normal,2012-11-26T04:20:03-0800,"Lauri Alanko [http://haskell.1045720.n5.nabble.com/Static-non-exported-stubs-td5713489.html suggests] that there should be a way to define a callback to a haskell function statically (i.e. without using a dynamic wrapper).

It is currently possible to do so only by exporting the function and reimporting it as a function pointer:

{{{
foreign export ccall ""my_callback"" myCallback :: IO ()
foreign import ccall ""&my_callback"" myCallbackPtr :: FunPtr (IO ())
}}}

but of course this not ideal because it creates an extra symbol (and is quirky).

A possible new syntax could be:

{{{
foreign import ccall myCallbackPtr :: FunPtr (IO ()) = myCallback
}}}

or variations thereof. We probably want to keep `import` (rather than `export` or some new keyword), since this declaration brings something into scope, like a normal FFI import.",pcapriotti
3,5722,35,"ireney.knapp@…, hvr@…",GHC inlines class method forever,Compiler,7.2.1,_|_,simonpj,new,normal,2011-12-28T06:00:10-0800,"irene-knapp showed me this over IRC, I refined the test case a bit:

{{{
{-# LANGUAGE FlexibleContexts, MultiParamTypeClasses #-}
module Bug () where

class C a b where
  discord :: C a b => a b () -- Remove the constraint and it works
  rhyme :: a b ()

instance C (,) b => C (,) [b] where
  discord = discord
  rhyme = discord
}}}
GHC 7.2.2 compiling this with -O loops forever. I've worked out:
 * The `C a b` context in the class is completely superfluous but the bug isn't triggered without it.
 * The pattern of recursion in the two method signatures is fragile: `rhyme = rhyme` doesn't trigger the bug, for example.
 * Adding a `NOINLINE discord` stops the bug from triggering. Similarly, compiling without optimisations doesn't trigger the bug.
 * While it's looping, GHC slowly but steadily chews through all of your memory.",benmachine
3,1405,35,"pho@…, slyfox@…",Make ghc (stage1) be compilable by non-GHC,Compiler,6.6.1,_|_,,new,normal,2010-07-17T12:14:57-0700,"This depends a bit on the existence of a good-enough non-GHC compiler.  Possibility to do recursively dependent modules (I think) presently rules out everything except JHC, which is not entirely working yet.  Also pattern guards might need to be implemented in that compiler.  Maybe for testing, a ghc that doesn't define __GLASGOW_HASKELL__ (and doesn't use ghc-specific flags ?? possibly a wrapper script of some sort) could be used too.

See http://thread.gmane.org/gmane.comp.lang.haskell.cvs.ghc/20962 ... GHC also uses things like IORefs, (unsafeCoerce? only in stage2 I think) that everyone provides, but would still be good to document.

I'm working on this now, we'll see how far I get --Isaac",Isaac Dupree
2,5620,34,"bill@…, idhameed@…",Dynamic linking and threading does not work on Windows,Runtime System,7.2.1,7.6.2,igloo,new,high,2013-04-06T22:33:10-0700,"On Windows, compile this module:
{{{
main = print 42
}}}
With this command:
{{{
ghc --make -threaded -dynamic Main.hs
}}}
Run, and watch it segfault.
",Lennart
2,7043,34,"pho@…, kazu@…",32-bit GHC ceiling of negative float SEGFAULT: 11,Compiler,7.4.1,7.6.2,igloo,new,high,2013-05-22T20:00:58-0700,"When taking the ceiling of a negative float (like -0.8) with GHCi installed by the 32-bit .dmg provided on haskell.org there is a Segmentation Fault: 11 that occurs.  This does not happen in the 64-bit version, which works properly.",DrGodCarl
3,5615,34,"dterei, carter.schonwald@…",ghc produces poor code for `div` with constant powers of 2.,Compiler,7.4.1-rc1,7.6.2,daniel.is.fischer,new,normal,2013-04-21T10:37:51-0700,"The code for Int {{{(div x c)}}} where {{{c}}} is a constant of the form 2^n^ should be implemented with an arithmetic right shift, currently it's a call to a function.  This optimization should be done for all signed types.

",Lennart
2,5902,33,"pho@…, exbb2@…",Cannot tell from an exception handler whether the exception was asynchronous,Compiler,7.4.1,7.8.1,simonmar,new,high,2013-05-03T03:46:51-0700,"Following on from #2558 which was closed (by me) as wontfix, we still don't have a way to reliably tell whether an exception we caught was asynchronous or not.  There are some suggestions in #2558, we just need to implement something.  The fix for #3997 was defficient due to this, as exposed by the test program in #5866.

",simonmar
3,4029,33,"judah.jacobson@…, blarsen",ghci leaks memory when loading a file,GHCi,,_|_,,new,normal,2010-08-11T06:27:23-0700,"In the 6.12 series, ghci leaks memory when loading definitions.  This appears to be a regression from previous releases.  The problem appears in both 6.12.1 and 6.12.2, but not in 6.8.3 or 6.10.4.

As a test, take the attached Hello World file, fire up ghci, and :load Hello.hs.  Watch the memory usage of ghci---each time you repeat the load command, the memory usage of the process grows.  (It grows slowly on this simple example, but on a real project, the growth can be several megabytes per :load.)

I discovered this due to my workflow.  When programming Haskell, I typically use emacs with haskell-mode, and frequently reload the definitions of the code I am working on.  After upgrading to 6.12.1, after coding for some time, I noticed my 8GB machine was swapping.  (It is faster to :reload the file rather than :load, and reloading doesn't appear to suffer from the memory leak, but sometimes I switch between modules and :reload is not applicable.)

My workaround for now is to regularly restart my ghci processes to prevent their memory usage from growing so much that my system starts swapping.

I have observed this bug on 32- and 64-bit GHCi on various versions of Ubuntu, on both Intel and AMD processors.
",blarsen
5,2986,33,glasgow-haskell-users@…,:info printing instances often isn't wanted,GHCi,6.10.1,7.6.2,Remi,new,lowest,2013-03-25T04:22:18-0700,":info shows all instances of types/classes, which often obscures the info I'm actually interested in.
See the output of e.g. "":info Show"" or "":info [] Maybe Int"": The class and types are rather lost in between the instances. My proposal is to add an option to suppress the printing of instances. With the attached patch for 6.10.1 (although it applies to HEAD too), "":info -Show"" will only print the class.",Remi
3,5641,32,"dterei, mail@…",The -L flag should not exist,Profiling,7.2.1,7.6.2,,new,normal,2012-10-05T07:35:49-0700,"Why does the -L flag exist?  The .hp file should contain untruncated strings, and any truncation of the names should be done in hp2ps.",augustss
3,4211,32,"pho@…, dmp@…",LLVM: Stack alignment on OSX,Compiler (LLVM),6.13,7.6.2,dterei,new,normal,2013-01-07T06:52:35-0800,"On OSX the ABI requires that the stack is 16 byte aligned when making function calls. (Although this only really needs to be obeyed when making calls that will go through the dynamic linker, so FFI calls). Since the stack is 16 byte aligned at the site of the call, on entry to a function most compilers (both llvm and gcc) expect the stack to now be aligned to 16n - 4, since 4 bytes should have been pushed for the return address as part of the call instruction. GHC though since it uses jumps everywhere keeps that stack at 16 byte aligned on function entrance. This means that LLVM generates incorrect stack alignment code, always off by 4.

For the moment I have handled this by using the LLvm Mangler (which is only needed on OS X already for TNTC) to simply correctly fix up the stack alignment code.

E.g Asm generated by LLVM: 
{{{
_func:
    subl $12, %esp
    ...
    call _sin
    ...
    addl $12, %esp
}}}

The mangler will change this to:
{{{
_func:
    subl $16, %esp
    ...
    call _sin
    ...
    addl $16, %esp
}}}

The better solution would be to change GHC to keep the stack at 16n - 4 alignment on function. This will require changing the RTS (StgCRun.hs) to set the stack properly before calling into Stg land and also fixing up the NCG to align code properly. There may also be a problem with the C backend as currently all function prolouge and epilouge code is stripped out, which means all the stack manipulation code generated by GCC is removed. This works fine now since the stack is already 16 byte aligned on entry, but if it is now 16n - 4 byte aligned then some stack manipulation will be required.",dterei
3,3676,32,daniel.is.fischer@…,realToFrac doesn't sanely convert between floating types,libraries (other),6.12.1,_|_,,new,normal,2011-07-29T16:39:37-0700,"As far as I can tell, the only way to convert between floating types in Haskell is to use realToFrac.  Unfortunately, this function does some insane mangling of values when converting.  Some examples:
{{{
realToFrac (0/0 :: Double) :: Double
  --> -Infinity
realToFrac (-1/0 :: Float) :: Double
  --> -3.402823669209385e38
realToFrac (-0 :: Double) :: CDouble
  --> 0.0
}}}
The last item illustrates an important point:  it is impossible to convert a value from Double to CDouble without potentially changing it.  This makes it difficult or impossible to use the FFI to call any functions with floating point parameters/return values.

Using a combination of unsafeCoerce (to shoehorn Double values in/out of CDoubles) and some functions written in C (to perform float<=>double), I was able to work around these problems, but that hardly seems like a nice solution.",draconx
5,2269,32,"daniel.is.fischer@…, dterei",Word type to Double or Float conversions are slower than Int conversions,Compiler,6.8.2,7.6.2,dons@…,new,lowest,2012-09-12T04:13:57-0700,"We have int2Double# and int2Float# primitives, but not equivalent ones for Word
types. We may need word2Double# too, for Words* to be fully first-class performance-wise.

This means we have to do extra tests in the Num instances for Word types
to implement 'fromIntegral':

{{{

    toInteger (W# x#)
        | i# >=# 0#             = smallInteger i#
        | otherwise             = wordToInteger x#
        where i# = word2Int# x#

}}}

Now, for some types, we work around this:

{{{

""fromIntegral/Int->Word""  fromIntegral = \(I# x#) -> W# (int2Word# x#)
""fromIntegral/Word->Int""  fromIntegral = \(W# x#) -> I# (word2Int# x#)
""fromIntegral/Word->Word"" fromIntegral = id :: Word -> Word

}}}

and so on for other Word/Int types. And all is fine.

The problem comes up for Float and Double. For Int, we can write:

{{{

""fromIntegral/Int->Float""   fromIntegral = int2Float
""fromIntegral/Int->Double""  fromIntegral = int2Double

int2Float :: Int -> Float
int2Float   (I# x) = F# (int2Float# x)

int2Double :: Int -> Double 
int2Double   (I# x) = D# (int2Double#   x)

}}}

But we can't write these rules for Word types.

The result is a slow down on Word conversions, consider this
program:

{{{

main = print . sumU
             . mapU (fromIntegral::Int->Double)
             $ enumFromToU 0 100000000

}}}

When in lhs is Int, we get this nice code:

{{{

$wfold :: Double# -> Int# -> Double#

$wfold =
  \ (ww_s18k :: Double#) (ww1_s18o :: Int#) ->
    case ># ww1_s18o 100000000 of wild_a14T {
      False ->
        $wfold
          (+## ww_s18k (int2Double# ww1_s18o)) (+# ww1_s18o 1);
      True -> ww_s18k


}}}

But for Word types, we get:

{{{

$wfold :: Double# -> Word# -> Double#

$wfold =
  \ (ww_s1gN :: Double#) (ww1_s1gR :: Word#) ->
    case gtWord# ww1_s1gR __word 100000000 of wild_a1do {
      False ->
        case case >=# (word2Int# ww1_s1gR) 0 of wild1_a1cS {
               False ->
                 case word2Integer# ww1_s1gR of wild11_a1d9 { (# s_a1db, d_a1dc #) ->
                 case {__ccall __encodeDouble Int#
                        -> ByteArray#
                        -> Int#
                        -> State# RealWorld
                        -> (# State# RealWorld, Double# #)}_a1bT
                        s_a1db d_a1dc 0 realWorld#
                 of wild12_a1bX { (# ds1_a1bZ, ds2_a1c0 #) ->
                 ds2_a1c0
                 }
                 };
               True -> int2Double# (word2Int# ww1_s1gR)
             }
        of wild1_a1bM { __DEFAULT ->
        $wfold
          (+## ww_s1gN wild1_a1bM) (plusWord# ww1_s1gR __word 1)
        };
      True -> ww_s1gN
    }

}}}

Which is to be expected, and the running time goes from:

{{{

$ time ./henning  
5.00000000067109e17
./henning  1.53s user 0.00s system 99% cpu 1.534 total

}}}

To:

{{{

$ time ./henning  
5.00000000067109e17
./henning  4.57s user 0.00s system 99% cpu 4.571 total

}}}

So not too bad, but still, principle of least surprise says Word and Int
should behave the same.

Should we have a word2Double# primop?",dons
5,2531,32,haskell.vivian.mcphail@…,Prune duplicates in ghci history,GHCi,6.8.3,7.6.2,,new,lowest,2012-09-12T04:14:01-0700,"When we enter the same expressions in ghci, all of them go in to history.
It'd be useful to have an option to eliminate duplicate expressions before storing them in ghci history.

We can also consider doing this for storing ghci history as a file.",venkat
3,7908,31,"dimitris@…, dreixel",InstanceSigs suggestion not accepted,Compiler,7.7,,,new,normal,2013-05-14T14:29:48-0700,"Attached testcase compiles, but when
uncommenting either of the lines 19, 21 or 23,
I get an error:

{{{
pr7908.hs:23:12:
    Method signature does not match class; it should be
      (>>-) :: forall (c :: k -> *) d.
               Hidden k c -> (forall (a :: k). c a -> d) -> d
    In the instance declaration for `Monad' k (Hidden k)'
Failed, modules loaded: none.
}}}

But in fact I basically copied the suggestion into my file! (with slight modification ""Hidden k c"" --> ""Hidden c"")

This may be because of the rank2 type or because of the polykinds appearing.",heisenbug
3,5761,31,"sol@…, kazu@…",Getting stdout and stderr as a single handle from createProcess does not work on Windows,libraries/process,,7.6.2,,new,normal,2012-09-12T04:12:08-0700,"The following test case works on Linux (an as far as I know on Mac OS X too), but not on Windows.
{{{
{-# OPTIONS_GHC -fno-warn-missing-signatures #-}
module Spec (main) where
import           Test.HUnit
import           System.Process
import           System.IO

subprocess = concat $
  [ ""module Main where\n""
  , ""import System.IO\n""
  , ""main = do\n""
  , ""  hPutStr stderr \""foo\""\n""
  , ""  hFlush stderr\n""
  , ""  hPutStrLn stdout \""bar\""\n""
  , ""  hFlush stdout\n""
  ]

main = runTestTT $ TestCase $ do
  (Just hin, Just hout, Nothing, _) <-
    createProcess $ (proc ""runhaskell"" []) {
        std_in = CreatePipe
      , std_out = CreatePipe
      , std_err = UseHandle stdout
    }
  hPutStrLn hin subprocess
  hClose hin
  line <- hGetLine hout
  line @?= ""foobar""
}}}

Do we consider this a bug?  If not, what would be the suggested way to do that?",SimonHengel
3,5928,30,"pho@…, fox@…",INLINABLE fails to specialize in presence of simple wrapper,Compiler,7.4.1,7.6.2,,new,normal,2013-01-08T15:47:43-0800,"If a function marked as `INLINABLE` is called indirectly through a simple wrapper defined in a different module, specialization never happens (i.e. none of the dictionaries are removed.)

Here's an example where it fails. First, the simple wrapper module:

{{{
module Repro where

import Data.Hashable
import Data.HashMap.Strict as M

infixl 9  !
(!) :: (Eq a, Hashable a) => M.HashMap a b -> a -> b
m ! x = case M.lookup x m of  -- lookup is INLINABLE
    Just y -> y
    Nothing -> error ""Repro.!""
}}}

and then the call site:

{{{
module Test (test) where

import Data.HashMap.Strict as M

import Repro

test :: M.HashMap Int Int -> Int
test m = m ! 42
}}}

To compile the code you need to `cabal install unordered-containers`. The relevant function (which is not getting specialized) from unordered-containers is:

{{{
lookup :: (Eq k, Hashable k) => k -> HashMap k v -> Maybe v
lookup k0 = go h0 k0 0
  where
    h0 = hash k0
    go !_ !_ !_ Empty = Nothing
    go h k _ (Leaf hx (L kx x))
        | h == hx && k == kx = Just x
        | otherwise          = Nothing
    go h k s (BitmapIndexed b v)
        | b .&. m == 0 = Nothing
        | otherwise    = go h k (s+bitsPerSubkey) (A.index v (sparseIndex b m))
      where m = mask h s
    go h k s (Full v) = go h k (s+bitsPerSubkey) (A.index v (index h s))
    go h k _ (Collision hx v)
        | h == hx   = lookupInArray k v
        | otherwise = Nothing
#if __GLASGOW_HASKELL__ >= 700
{-# INLINABLE lookup #-}
#endif
}}}

If `test` calls `lookup` directly, without using the `(!)` wrapper, things get specialized. Manually marking `(!)` as `INLINABLE` works, but users shouldn't have to do that.

The core for `Repro` and `Test` is:

{{{
$ ghc -O2 Test.hs -fforce-recomp -ddump-simpl 
[1 of 2] Compiling Repro            ( Repro.hs, Repro.o )

==================== Tidy Core ====================
Result size = 28

lvl_rNZ :: [GHC.Types.Char]
[GblId]
lvl_rNZ = GHC.CString.unpackCString# ""Repro.!""

Repro.!1 :: forall b_aBU. b_aBU
[GblId, Str=DmdType b]
Repro.!1 = \ (@ b_aBU) -> GHC.Err.error @ b_aBU lvl_rNZ

Repro.!
  :: forall a_atJ b_atK.
     (GHC.Classes.Eq a_atJ, Data.Hashable.Hashable a_atJ) =>
     Data.HashMap.Base.HashMap a_atJ b_atK -> a_atJ -> b_atK
[GblId,
 Arity=4,
 Str=DmdType LLLL,
 Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=4, Value=True,
         ConLike=True, Cheap=True, Expandable=True,
         Guidance=IF_ARGS [0 0 0 0] 70 0}]
Repro.! =
  \ (@ a_aBT)
    (@ b_aBU)
    ($dEq_aBV :: GHC.Classes.Eq a_aBT)
    ($dHashable_aBW :: Data.Hashable.Hashable a_aBT)
    (m_atL :: Data.HashMap.Base.HashMap a_aBT b_aBU)
    (x_atM :: a_aBT) ->
    case Data.HashMap.Base.lookup
           @ a_aBT @ b_aBU $dEq_aBV $dHashable_aBW x_atM m_atL
    of _ {
      Data.Maybe.Nothing -> Repro.!1 @ b_aBU;
      Data.Maybe.Just y_atN -> y_atN
    }



[2 of 2] Compiling Test             ( Test.hs, Test.o )

==================== Tidy Core ====================
Result size = 20

Test.test2 :: GHC.Types.Int
[GblId,
 Caf=NoCafRefs,
 Str=DmdType m,
 Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True,
         ConLike=True, Cheap=True, Expandable=True,
         Guidance=IF_ARGS [] 10 110}]
Test.test2 = GHC.Types.I# 42

Test.test1
  :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int
     -> Data.Maybe.Maybe GHC.Types.Int
[GblId,
 Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False,
         ConLike=False, Cheap=False, Expandable=False,
         Guidance=IF_ARGS [] 40 0}]
Test.test1 =
  Data.HashMap.Base.lookup
    @ GHC.Types.Int
    @ GHC.Types.Int
    GHC.Classes.$fEqInt
    Data.Hashable.$fHashableInt
    Test.test2

Test.test
  :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int
     -> GHC.Types.Int
[GblId,
 Arity=1,
 Str=DmdType L,
 Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True,
         ConLike=True, Cheap=True, Expandable=True,
         Guidance=IF_ARGS [0] 40 0}]
Test.test =
  \ (m_aPx
       :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int) ->
    case Test.test1 m_aPx of _ {
      Data.Maybe.Nothing -> Repro.!1 @ GHC.Types.Int;
      Data.Maybe.Just y_atN -> y_atN
    }
}}}
",tibbe
3,1526,30,id@…,-fobject-code doesn't apply to expressions typed at the prompt,Compiler,6.7,_|_,,new,normal,2013-01-22T15:29:18-0800,"While looking to see if I could easily fix #1525 myself, I saw a suspicious modification to the unboxed tuples error; examining more closely:

{{{
stefan@stefans:~/qhc/qhc-desugar/Qhc/TypeCheck$ ghci
Loading package base ... linking ... done.
   ___         ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |    GHC Interactive, version 6.7.20070612, for Haskell 98.
/ /_\\/ __  / /___| |    http://www.haskell.org/ghc/
\____/\/ /_/\____/|_|    Type :? for help.

Prelude> :set -fglasgow-exts 
Prelude> let foo x y = (# x, y #)
Error: bytecode compiler can't handle unboxed tuples.
  Possibly due to foreign import/export decls in source.
  Workaround: use -fobject-code, or compile this module to .o separately.
Prelude> :set -fobject-code
Prelude> let foo x y = (# x, y #)
Error: bytecode compiler can't handle unboxed tuples.
  Possibly due to foreign import/export decls in source.
  Workaround: use -fobject-code, or compile this module to .o separately.
Prelude> 
}}}

so the suggested workaround doesn't actually work.  I can certainly imagine a model of GHC compilation where the NCG doesn't support anonymous modules; in which case the easiest fix would be to tweak the error message.  But interactive, optimizing, native compilation *does* sound like a cool and relatively cheap-to-implement feature :)",sorear
3,3447,30,Conor.McBride@…,Class restrictions on type instances,Compiler,6.10.4,_|_,,new,normal,2009-08-26T04:20:18-0700,"I'm using type families to implement bools and integers on type level.

There is a class BoolT with with two instances and type families representing usual boolean functions, e.g. NotT. By semantics of NotT, implication (BoolT a) => (BoolT (NotT a)) holds, but I cannot specify this to compiler, and using BoolT with NotT is painful.

So I think there must be syntactic construction to restrict type family instances to some class, something like

{{{
type family NotT a 
    with (BoolT a) => (BoolT (NotT a))
}}}
or
{{{
class BoolT a where
    type NotT a
        with BoolT (NotT a)
}}}
",LysikovVV
4,1628,30,id@…,warning(s) for using stolen syntax that's not currently enabled,Compiler,6.6.1,_|_,,new,low,2013-01-26T14:24:56-0800,"Turning on `-fglasgow-exts` makes {{{f x = id$x}}} break.  I propose having a flag to warn about things like this, enabled by `-Wall`.  To be precise, ""stolen syntax"" is syntax that means something valid in (usually) Haskell98 and something different with some extension enabled.  If there are syntax-stealing extensions implemented by other non-GHC compilers, we may want to warn about those too.  (This includes all keywords, possibly other words like ""forall"", ""exists"", ""family"", unicode symbols for `->` and others...)

If anyone actually agrees on or implements a (optional) change to unary-minus, this would subsume the warning aspects of #1318.",Isaac Dupree
2,7277,29,hackage.haskell.org@…,Recompilation check fails for TH unless functions are inlined,Template Haskell,7.4.2,7.6.2,,new,high,2013-03-25T18:22:53-0700,"Even though [http://hackage.haskell.org/trac/ghc/ticket/481 Issue 481] is marked as closed, the fix is only partial. If a function inside $( ... ) is not inlined, then the dependency check fails. Attached is a full example, built around the following code:

{{{
#ifdef NO_INLINE
{-# NOINLINE libraryFunction #-}
#endif

libraryFunction :: Q Exp
libraryFunction = [e| ""Return X"" |]
}}}

And the test:

{{{
case_library_function = $( libraryFunction ) @?= ""Return A""
}}}

Here is are the relevant parts of RUNME.LOG:

{{{
+ rm -rf dist
+ cabal configure --enable-tests
Resolving dependencies...
Configuring dependency-bug-0.0.1...
+ sed -e 's/Return ./Return A/' -i src/Dependency/Library.hs
+ cabal build
Building dependency-bug-0.0.1...
Preprocessing library dependency-bug-0.0.1...
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.o )
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.p_o )
Registering dependency-bug-0.0.1...
Preprocessing test suite 'Test' for dependency-bug-0.0.1...
[1 of 1] Compiling Main             ( test/Main.hs, dist/build/Test/Test-tmp/Main.o )
Linking dist/build/Test/Test ...
+ cabal test
Running 1 test suites...
Test suite Test: RUNNING...
Test suite Test: PASS
Test suite logged to: dist/test/dependency-bug-0.0.1-Test.log
1 of 1 test suites (1 of 1 test cases) passed.
+ sed -e 's/Return ./Return B/' -i src/Dependency/Library.hs
+ cabal build
Building dependency-bug-0.0.1...
Preprocessing library dependency-bug-0.0.1...
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.o )
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.p_o )
Registering dependency-bug-0.0.1...
Preprocessing test suite 'Test' for dependency-bug-0.0.1...
[1 of 1] Compiling Main             ( test/Main.hs, dist/build/Test/Test-tmp/Main.o )
Linking dist/build/Test/Test ...
+ cabal test
Running 1 test suites...
Test suite Test: RUNNING...
Main:
  library function: [Failed]
expected: ""Return A""
 but got: ""Return B""

         Test Cases  Total
 Passed  0           0
 Failed  1           1
 Total   1           1
Test suite Test: FAIL
Test suite logged to: dist/test/dependency-bug-0.0.1-Test.log
0 of 1 test suites (0 of 1 test cases) passed.

}}}

This is as expected; we changed the source to ""Return B"" but the test expects the library to ""Return A"" so it fails. So far, so good. However:

{{{
+ rm -rf dist
+ cabal configure --enable-tests -fwithout-inline
Resolving dependencies...
Configuring dependency-bug-0.0.1...
+ sed -e 's/Return ./Return A/' -i src/Dependency/Library.hs
+ cabal build
Building dependency-bug-0.0.1...
Preprocessing library dependency-bug-0.0.1...
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.o )
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.p_o )
Registering dependency-bug-0.0.1...
Preprocessing test suite 'Test' for dependency-bug-0.0.1...
[1 of 1] Compiling Main             ( test/Main.hs, dist/build/Test/Test-tmp/Main.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package containers-0.4.2.1 ... linking ... done.
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package dependency-bug-0.0.1 ... linking ... done.
Loading package filepath-1.3.0.0 ... linking ... done.
Loading package old-locale-1.0.0.4 ... linking ... done.
Loading package old-time-1.1.0.0 ... linking ... done.
Loading package bytestring-0.9.2.1 ... linking ... done.
Loading package unix-2.5.1.1 ... linking ... done.
Loading package directory-1.1.0.2 ... linking ... done.
Loading package cpphs-1.14 ... linking ... done.
Loading package haskell-src-exts-1.13.5 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package regex-base-0.93.2 ... linking ... done.
Loading package regex-posix-0.95.2 ... linking ... done.
Loading package language-haskell-extract-0.2.1 ... linking ... done.
Loading package ansi-terminal-0.5.5 ... linking ... done.
Loading package ansi-wl-pprint-0.6.4 ... linking ... done.
Loading package extensible-exceptions-0.1.1.4 ... linking ... done.
Loading package hostname-1.0 ... linking ... done.
Loading package time-1.4 ... linking ... done.
Loading package random-1.0.1.1 ... linking ... done.
Loading package text-0.11.2.3 ... linking ... done.
Loading package xml-1.3.12 ... linking ... done.
Loading package test-framework-0.6.1 ... linking ... done.
Loading package test-framework-th-0.2.2 ... linking ... done.
Loading package HUnit-1.2.5.1 ... linking ... done.
Loading package test-framework-hunit-0.2.7 ... linking ... done.
Linking dist/build/Test/Test ...
+ cabal test
Running 1 test suites...
Test suite Test: RUNNING...
Test suite Test: PASS
Test suite logged to: dist/test/dependency-bug-0.0.1-Test.log
1 of 1 test suites (1 of 1 test cases) passed.
+ sed -e 's/Return ./Return B/' -i src/Dependency/Library.hs
+ cabal build
Building dependency-bug-0.0.1...
Preprocessing library dependency-bug-0.0.1...
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.o )
[1 of 1] Compiling Dependency.Library ( src/Dependency/Library.hs, dist/build/Dependency/Library.p_o )
Registering dependency-bug-0.0.1...
Preprocessing test suite 'Test' for dependency-bug-0.0.1...
Linking dist/build/Test/Test ...
+ cabal test
Running 1 test suites...
Test suite Test: RUNNING...
Test suite Test: PASS
Test suite logged to: dist/test/dependency-bug-0.0.1-Test.log
1 of 1 test suites (1 of 1 test cases) passed.
}}}

As you can see, without-inline the 2nd build did not recompile the test, even though it should have. It only re-linked the test, so it kept seeing ""Return A"" even though the library actually does ""Return B"".

In my real code, there are no NO/INLINE pragmas; however, the TH code is complex enough that it is not inlined, which causes the same problem. I had to use the pragma to keep the example short.",orenbenkiki
2,6022,29,hackage.haskell.org@…,GHC infers over-general types,Compiler,7.4.1,7.8.1,simonpj,new,high,2013-03-25T18:38:45-0700,"Consider
{{{
f x = x + head
}}}
GHC will (with no flags) will compile this almost-certainly-wrong program, giving `f` the type
{{{
    f :: forall a. Num ([a] -> a) => ([a] -> a) -> [a] -> a
}}}
There's nothing wrong with that type, and in principle someone might later define a suitable instance of `Num`, but (a) it's not Haskell 98, and (b) it's unlikely to be right, so we've deferred a type error from the definition site of `f` to the (perhaps much later) call site.

I think GHC should complain, and require a type signature if that's what you really want.  This came up on [http://stackoverflow.com/questions/10091874/haskell-why-is-there-no-type-mismatch-and-why-does-this-compile Stackoverflow]",simonpj
2,7152,29,hackage.haskell.org@…,Add flag to configure that skips overwriting of symlinks on install,Build System,7.4.2,7.8.1,,new,high,2013-03-25T18:31:26-0700,"Sometimes when I'm installing a GHC release candidates I'd like to install the RC without overwriting the `ghc` etc symlinks in `/usr/local/bin`. It would be convenient to have a configure flag that told the install step to only install the versioned binaries (e.g. `ghc-6.2.1`) in `/usr/local/bin`, without the symlinks.",tibbe
2,4243,29,hackage.haskell.org@…,Make a proper options parser for the RTS,Runtime System,6.13,7.8.1,,new,high,2013-03-22T03:19:32-0700,"The RTS options parsing is getting increasingly crufty, and the new `rtsOptsEnabled` options have made it even worse. We should really have a proper options parser.
",igloo
3,7862,29,hackage.haskell.org@…,"Could not deduce (A) from the context (A, ...)",Compiler (Type checker),7.6.2,,,new,normal,2013-05-03T02:45:27-0700,"The following code doesn't compile and produces a strange error:

{{{
{-# LANGUAGE TypeFamilies, FlexibleContexts #-}

module Numeric.AD.Internal.Tower () where

type family Scalar t

newtype Tower s a = Tower [a]

type instance Scalar (Tower s a) = a

class (Num (Scalar t), Num t) => Mode t where
    (<+>) :: t -> t -> t

instance (Num a) => Mode (Tower s a) where
    Tower as <+> _ = undefined
      where
        _ = (Tower as) <+> (Tower as)

instance Num a => Num (Tower s a) where
}}}

{{{
src/Numeric/AD/Internal/Tower.hs:17:24:
    Could not deduce (Num (Scalar (Tower s a)))
      arising from a use of `<+>'
    from the context (Num (Scalar (Tower s a)), Num (Tower s a), Num a)
      bound by the instance declaration
      at src/Numeric/AD/Internal/Tower.hs:14:10-36
    Possible fix:
      add an instance declaration for (Num (Scalar (Tower s a)))
    In the expression: (Tower as) <+> (Tower as)
    In a pattern binding: _ = (Tower as) <+> (Tower as)
    In an equation for `<+>':
        (Tower as) <+> _
          = undefined
          where
              _ = (Tower as) <+> (Tower as)
}}}

Furthermore, Removing the {{{Num (Scalar t)}}} constraint from the {{{Mode}}} class produces a different strange error:
{{{
src/Numeric/AD/Internal/Tower.hs:17:24:
    Overlapping instances for Num (Tower s0 a)
      arising from a use of `<+>'
    Matching givens (or their superclasses):
      (Num (Tower s a))
        bound by the instance declaration
        at src/Numeric/AD/Internal/Tower.hs:14:10-36
    Matching instances:
      instance Num a => Num (Tower s a)
        -- Defined at src/Numeric/AD/Internal/Tower.hs:19:10
    (The choice depends on the instantiation of `a, s0')
    In the expression: (Tower as) <+> (Tower as)
    In a pattern binding: _ = (Tower as) <+> (Tower as)
    In an equation for `<+>':
        (Tower as) <+> _
          = undefined
          where
              _ = (Tower as) <+> (Tower as)
}}}",alang9
3,7473,29,the.dead.shall.rise@…,getModificationTime gives only second-level resolution,libraries/directory,7.6.1,7.8.1,,new,normal,2013-04-30T04:57:56-0700,"The `System.Directory.getModificationTime` function only returns time with second-level granularity. This is no good for applications like `ghc --make` where we need to compare file timestamps.

The fix should be simple, here's a patch (compiles but not tested) that should fix it for Unix, for Windows we will need a different fix, probably using the Win32 API directly, rather than the mingw C api.
{{{
diff --git a/System/Directory.hs b/System/Directory.hs
index cfe7cd9..f27bfc4 100644
--- a/System/Directory.hs
+++ b/System/Directory.hs
@@ -995,14 +995,14 @@ The operation may fail with:
 getModificationTime :: FilePath -> IO UTCTime
 getModificationTime name = do
 #ifdef mingw32_HOST_OS
- -- ToDo: use Win32 API
+ -- ToDo: use Win32 API so we can get sub-second resolution
  withFileStatus ""getModificationTime"" name $ \ st -> do
  modificationTime st
 #else
   stat <- Posix.getFileStatus name
-  let mod_time :: Posix.EpochTime
-      mod_time = Posix.modificationTime stat
-  return $ posixSecondsToUTCTime $ realToFrac mod_time
+  let mod_time :: POSIXTime
+      mod_time = Posix.modificationTimeHiRes stat
+  return $! posixSecondsToUTCTime mod_time
 #endif
 
 #endif /* __GLASGOW_HASKELL__ */
}}}",duncan
3,7169,29,the.dead.shall.rise@…,Warning for incomplete record field label used as function,Compiler,7.7,7.8.1,,new,normal,2013-04-24T06:28:27-0700,"Consider the following definition:

{{{
data Foo = Bar { frob :: Int }
         | Baz { frob :: Int, quux :: Bool }
}}}

It would be great if GHC could produce a warning if I use {{{quux}}} as a function somewhere in my code, as calling {{{quux}}} on a {{{Foo}}} constructed with {{{Bar}}} will cause a runtime error. On the other hand, every use of {{{frob}}} is OK.

Currently, to find such problems, I have to first figure out which field labels are incomplete and then search for those, ignoring their uses as a proper field label (in construction or pattern matching).",goldfire
3,7647,29,hackage.haskell.org@…,UNPACK polymorphic fields,Compiler,7.6.1,7.8.1,simonpj,new,normal,2013-04-12T16:54:34-0700,"comment:9:ticket:3990 mentions the possibility of unpacking polymorphic fields. To quote:

  […]

  What I mean by ""polymorphic unpack"" is this:
{{{
  data Poly a = MkP Bool {-# UNPACK #-} a 
  data Mango = MkMango {-# UNPACK #-} (Poly Int)
}}}
  Now a value of type Poly t would be represented using two pointer fields, as usual (ie the UNPACK would have no direct effect on Poly). But a Mango value would be represented thus:
{{{
  data Mango = MkMangoRep Bool Int#

  MkMango :: Poly Int -> MangoRep
  MkMango (MkP b (I# i)) = MkMangoRep b i

  -- Pattern match      (MkMango p -> rhs)
  -- is transformed to  (MkMangoRep b i -> let p = MkP b (I# i) in rhs
}}}

Something like that would be rather nice. This ticket is just a reminder.

Thanks,[[br]]
/Liyang",liyang
3,855,29,hackage.haskell.org@…,Improvements to SpecConstr,Compiler,6.4.2,_|_,,new,normal,2013-03-25T18:24:51-0700,"There are a series of possible improvemnts to SpecConstr, described in 
the source code.  {{{compiler/specialise/SpecConstr}}}

 *  Specialising for constant parameters
 * Specialising for lambda parameters
 * Two ideas to do with strictness that look more tricky

Some of them look quite straightforward.",simonpj
3,2233,29,"Deewiant, anton.nik@…",Overhaul System.Process,libraries/process,6.8.2,_|_,simonmar,new,normal,2012-09-07T12:23:21-0700,"== Overhaul of System.Process ==

From the patch:

{{{
Tue Apr 22 15:02:16 PDT 2008  Simon Marlow <simonmarhaskell@gmail.com>
  * Overhall System.Process
     
   - fix #1780: pipes created by runInteractiveProcess are set
     close-on-exec by default
   
   - add a new, more general, form of process creation: createProcess
     Each of stdin, stdout and stderr may individually be taken
     from existing Handles or attached to new pipes.  Also it
     has a nicer API.
   
   - add readProcess from Don Stewart's newpopen package.  This
     function behaves like C's popen().
  
   - Move System.Cmd.{system,rawSystem} into System.Process.  Later
     we can depecate System.Cmd.
   
   - Don't use O_NONBLOCK for pipes, as it can confuse the process
     attached to the pipe (requires a fix to GHC.Handle in the base
     package).
  
   - move the tests from the GHC testsuite into the package itself,
     and add a couple more
  
   - bump the version to 2.0
}}}

Haddock for the new API is here: [http://darcs.haskell.org/~simonmar/process/System-Process.html]

Patch is attached.  So far I've only modified the Unix parts of the code, the Windows parts still need to be updated.

Discussion period: 4 weeks (20 May)
",simonmar
4,4210,29,william.knop.nospam@…,LLVM: Dynamic Library Support,Compiler (LLVM),6.13,7.6.2,dterei,new,low,2013-05-15T00:28:26-0700,"dynamic library status:
{{{
 * Supported: Linux 64bit, Mac OSX 64bit
 * Unsupported: Linux 32bit, Mac OSX 32bit, Windows 32bit
}}}

The LLVM backend doesn't support dynamic libraries at the moment.

LLC supports a flag called '-relocation-mode' that can be used to support this, it takes the following options:

{{{
default        - let the target choose.
static         - static code.
pic            - PIC code.
dynamic-no-pic - Dynamic references but static code
}}}

This roughly corresponds to GHC -fPIC, and -dynamic flags.

Linux: Simply adding the correct flag to LLC seems to work fine.
Mac OSX, Windows: Adding the correct flag doesn't work at all, all programs segfault.",dterei
5,1894,29,"b.hilken@…, sorear",Add a total order on type constructors,Compiler (Type checker),6.8.1,7.6.2,,new,lowest,2013-01-26T20:04:49-0800,"Several proposals for ExtensibleRecords can be implemented as libraries if type constructors can be ordered globally.

This proposal is to add built-in types:
{{{
data LabelLT
data LabelEQ
data LabelGT
type family LabelCMP
}}}
such that, for any two datatypes
{{{
data N = N
data M = M
}}}
the instance {{{LabelCMP N M}}} takes one of the values {{{LabelLT, LabelEQ, LabelGT}}} depending on the lexicographic ordering on the fully-qualified names of {{{N}}} and {{{M}}}.



",guest
1,7953,28,"simonmar, pho@…",Segfault on x86 with -O2,Compiler,7.7,7.8.1,,new,highest,2013-06-18T18:45:59-0700,"
First reported by Kazu Yamamoto in http://www.haskell.org/pipermail/ghc-devs/2013-May/001346.html

On OSX x86 with 7.7.20130530:
{{{
$ ghc --make Main -O2 -Wall
[1 of 1] Compiling Main             ( Main.hs, Main.o )
Linking Main ...
$ ./Main
Winner (E {_key = 156, prio = 9.443531728518195e-3}) (LLoser [...]
Before atMost
[E {_key = 2, prio = 6.2447874501499356e-2},[...]prio = 0.35312841343485957}Segmentation fault: 11
}}}
It randomly fails with either ""Segmentation fault: 11"" or ""Bus error: 10"". Sometimes it succeeds.

With `-O` it apparently always succeeds.
",igloo
2,7316,28,"bgamari, cjwatson@…",GHC segfaults on ARM,Compiler,7.4.2,7.6.2,,new,high,2013-05-10T12:58:08-0700,"Sorry for the lack of detail. I thought I'd file this upstream. We've been seeing this in Ubuntu with 7.4.2. Some cabal packages, like chell, fail to build with a segfault in ghc.

{{{
[3 of 4] Compiling Test.Chell.Main  ( lib/Test/Chell/Main.hs, dist-ghc/build/Test/Chell/Main.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.0 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package old-locale-1.0.0.4 ... linking ... done.
Loading package time-1.4 ... linking ... done.
Loading package random-1.0.1.1 ... linking ... done.
Loading package containers-0.4.2.1 ... linking ... done.
Loading package patience-0.1.1 ... linking ... done.
Loading package bytestring-0.9.2.1 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package monads-tf-0.1.0.0 ... linking ... done.
Loading package text-0.11.2.0 ... linking ... done.
Loading package system-filepath-0.4.6 ... linking ... done.
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package options-0.1.1 ... linking ... done.
make: *** [build-ghc-stamp] Error 11
}}}

Full build log attached. I'll try to reduce the example and/or reproduce with 7.6 soon. (I can also provide you with SSH access to hardware if you need it).",laney
2,7646,28,leuschner@…,resource busy (file is locked) with multi-threaded file ops,libraries/base,7.6.2,7.6.3,simonmar,merge,high,2013-02-04T04:28:11-0800,"The sample program attached creates 10 worker threads, each of which takes a different file name. Each worker thread then writes the file, reads the file, writes the file and so on. File operations use *strict IO*.

When compiled without `-threaded` everything is ok, that is, the program goes on forever without any error messages.

But with `-threaded`, the program quickly fails with `ERROR in worker 4: 4: openBinaryFile: resource busy (file is locked)`.

Tested under Mac OSX 10.8.2 and Linux.
Tested with both GHC 7.6.1 and 7.6.2.

I could reproduce the bug without +RTS -N -RTS and with this RTS option. A colleague of mine reports that it needs  +RTS -N2 -RTS to reproduce the bug.",StefanWehr
3,2057,27,nicolas.pouillard@…,inconsistent .hi file error gets ignored,Compiler,6.8.2,_|_,,new,normal,2008-09-30T08:51:40-0700,"{{{
[20 of 20] Compiling Main             ( ./Main.hs, dist/build/cabal/cabal-tmp/Main.o )
The interface for `main:Hackage.Config'
Declaration for savedConfigToConfigFlags
Unfolding of Hackage.Config.savedConfigToConfigFlags:
  Can't find interface-file declaration for variable Distribution.Simple.Setup.a401
    Probable cause: bug in .hi-boot file, or inconsistent .hi file
    Use -ddump-if-trace to get an idea of which file caused the error
Linking dist/build/cabal/cabal ...
dist/build/cabal/cabal-tmp/Hackage/Config.o: In function `sfsu_info':
(.text+0x70cc): undefined reference to `Cabalzm1zi3zi3_DistributionziSimpleziSetup_a401_closure'
dist/build/cabal/cabal-tmp/Hackage/Config.o: In function `rf7U_closure':
(.data+0xf28): undefined reference to `Cabalzm1zi3zi3_DistributionziSimpleziSetup_a401_closure'
collect2: ld returned 1 exit status
}}}

Now, the inconsistent .hi file was entirely my fault. However note that `ghc --make` did not stop at the error! It continued and tried to link.

This is bad because sometimes linker errors are very long and a user might loose the real source of the error.

The error gets raised in `iface/TcIface.lhs` by `importDecl`. The uses of that function look like they are translating the error into failure in other monads ok. It's not immediately obvious at what point in the propagation of this error it gets ignored and linking continues irrespective.

It should not be too hard to reproduce I hope. Generating inconsistent .hi files is fairly easy to do. In this case I just built cabal-install against an existing Cabal. Then rebuilt and re-registered a slightly changed Cabal lib. Then did another build of cabal-install without cleaning first.",duncan
3,2489,27,"ndmitchell@…, claus",Registry keys are created in per-user HKCU instead of system-wide HKLM,None,6.8.3,_|_,,new,normal,2009-11-21T04:59:13-0800,"This bug is related to #1515. The installer shouldn't create any keys under HKCU, and should use system-wide HKLM instead.

Now, the registry key is accessible only to the user who installed the GHC. Other users don't have the installation path in the registry, and this breaks all tools which rely on getting the installation path from the registry.",nimnul
3,5444,26,"bos@…, dterei",Slow 64-bit primops on 32 bit system,Compiler,7.2.1,7.6.2,,new,normal,2012-09-12T04:12:03-0700,"GHC primops for 64-bit arithmetic are implemented as FFI calls. It leads to serious performance penalty for 32 bit code which heavily uses 64-bit arithmetics.

I found this while investigating poor performance of mwc-random on 32-bit systems. 32-bit build runs 3-4 times slower than 64-bit build on the same hardware. It's difficult to estimate how faster would run optimal implementation since it doesn't exist. But it's probably at least 2x slowdown.


Here is simple program to demonstrate issue
{{{
sqr64 :: Int32 -> Int64
sqr64 x = y * y where y = fromIntegral x
}}}

Here is optimized core
{{{
$wsqr64 :: Int# -> Int64
$wsqr64 =
  \ (ww_sGO :: Int#) ->
    case {__pkg_ccall ghc-prim hs_intToInt64 Int#
                                    -> State# RealWorld -> (# State# RealWorld, Int64# #)}_aFY
           ww_sGO realWorld#
    of _ { (# _, ds2_aG2 #) ->
    case {__pkg_ccall ghc-prim hs_timesInt64 Int64#
                                    -> Int64# -> State# RealWorld -> (# State# RealWorld, Int64# #)}_aGc
           ds2_aG2 ds2_aG2 realWorld#
    of _ { (# _, ds4_aGi #) ->
    I64# ds4_aGi
    }
    }

sqr64 :: Int32 -> Int64
sqr64 = \ (w_sGM :: Int32) ->
    case w_sGM of _ { I32# ww_sGO -> $wsqr64 ww_sGO }
}}}",Khudyakov
3,5916,26,carter.schonwald@…,runST isn't free,Compiler,7.4.1,7.6.2,,new,normal,2013-04-05T22:34:20-0700,"While optimizing some code I discovered that `runST` isn't free. I had a function on the form:

{{{
f ... = ...let x = runST in (f x)...
}}}

Manually transforming it into

{{{
f ... = runST (g ...)
 where g ... = do
    ...
    x <- ...
    g x
    ...
}}}

(The real example is at https://github.com/tibbe/unordered-containers/commit/58b7815a057b3575c58b746d5971d59d806b1333)

improved performance quite a bit on this, already highly tuned, function. Unfortunately, combining all the calls to `runST` into one and pulling them ""up"" is not all good. The code is now less modular, has a somewhat over specified evaluation order, and generally looks more imperative.

The cause of the decrease in performance is that `runSTRep` cannot be inlined, which causes allocation of closures inline in the code (where none should be necessary.)

The comment next to `runSTRep` explains why it's implemented the way it is, but I wonder if matters could be improved by making it a primop. If we create a fresh state token every time, instead of reusing `realWorld#`, it should be impossible for mutable structures to let-float and become CAFs (which is what `runSTRep` tries to avoid.)",tibbe
3,7520,26,carter.schonwald@…,Implement cardinality analysis,Compiler,7.6.1,7.8.1,,new,normal,2013-04-12T14:37:59-0700,"Ilya is well on the way to a cardinality analyser.  Today I realised that it'll help a lot with CPS-heavy code.  For example, here's what happens with
{{{
data DT = DT {
                field1 :: Int
              , field2 :: Int
              , field3 :: Int }
  deriving( Read )
}}}
After strictness analysis and simplification we get this:
{{{
$wa_sD5 =
  \ (ww_sD1 :: GHC.Prim.Int#)
    (@ b_awu)
    (w_sD3 :: W2.DT -> Text.ParserCombinators.ReadP.P b_awu) ->
    case GHC.Prim.<=# ww_sD1 11 of _ {
      GHC.Types.False -> Text.ParserCombinators.ReadP.Fail @ b_awu;
      GHC.Types.True ->
        Text.Read.Lex.expect1
          a_su6
          @ b_awu
          (\ _ ->
             Text.Read.Lex.expect1
               a_suf
               @ b_awu
               (\ _ ->
                  Text.Read.Lex.expect1
                    a_sum
                    @ b_awu
                    (\ _ ->
                       Text.Read.Lex.expect1
                         a_suv
                         @ b_awu
                         (\ _ ->
                            GHC.Read.$fReadInt5
                              GHC.Read.$fReadInt_$sconvertInt
                              Text.ParserCombinators.ReadPrec.minPrec
                              @ b_awu
                              (\ (a2_XB0 [Dmd=Just L] :: GHC.Types.Int) ->
                                 Text.Read.Lex.expect1
                                   lvl_svA
                                   @ b_awu
                                   (\ _ ->
                                      Text.Read.Lex.expect1
                                        lvl_svE
                                        @ b_awu
                                        (\ _ ->
                                           Text.Read.Lex.expect1
                                             lvl_svI
                                             @ b_awu
                                             (\ _ ->
                                                GHC.Read.$fReadInt5
                                                  GHC.Read.$fReadInt_$sconvertInt
                                                  Text.ParserCombinators.ReadPrec.minPrec
                                                  @ b_awu
                                                  (\ (a2_XBa [Dmd=Just L] :: GHC.Types.Int) ->
...
}}}
Look at all those nested continuations! Then the subsequent float-out pass floats out lots of MFEs, but entirely fruitlessly because all these are actually one-shot lambdas.

I'm not certain that the analysis will catch them all, but it might.",simonpj
3,7309,26,carter.schonwald@…,"The Ix instance for (,) leaks space in range",libraries (other),7.6.1,_|_,,new,normal,2013-04-12T08:05:04-0700,"(at least if you take leak to mean unexpected space behaviour).

This was brought to my attention via http://stackoverflow.com/questions/12780497/puzzling-memory-behavior-in-haskell where someone created a `6×10^6`-array and was surprised that showing the array caused an additional `(3+2)*8*10^6` bytes to be used. The reason (as far as I could tell) was this code:

{{{
instance (Ix a, Ix b) => Ix (a, b) where
    range ((l1,l2),(u1,u2)) = [ (i1,i2) | i1 <- range (l1,u1), i2 <- range (l2,u2) ]
}}}
in Arr.GHC. The result of {{{range (l2,u2)}}} is shared between every step in the first component of the index.

I guess it is reasonable to expect that the result of range is never worth sharing (is it?). I am not entirely sure what the best, cleanest, alternative implementation is, though. (At least not without a working ```dontshare``` annotation ;-))",nomeata
4,5267,26,"ross@…, peteg",Missing type checks for arrow command combinators,Compiler (Type checker),7.0.3,7.6.2,ross,new,low,2012-09-12T04:13:30-0700,"Is this expected to work?

{{{
{-# LANGUAGE Arrows #-}
module T where

import Prelude
import Control.Arrow

t = proc () ->
     do rec x <- arr id <<< (| (arr id) (returnA -< x) |)
        returnA -< x

t' = proc x ->
     do x <- arr id <<< (| (arr id) (returnA -< x) |)
        returnA -< x

t'' = proc x ->
     do x <- arr id <<< (| (arr id) (returnA -< 3) |)
        returnA -< x

t''' = proc x -> arr id <<< (| (arr id) (returnA -< 3) |)
}}}

I get:

{{{
/tmp/T.hs:8:18:
    The type of the first argument of a command form has the wrong shape
      Argument type: t_tX
    In the command: (arr id) <<< ((|(arr id) ((returnA -< x))|))
    In a stmt of a 'do' expression:
        x <- (arr id) <<< ((|(arr id) ((returnA -< x))|))
    In a stmt of a 'do' expression:
        rec {x <- (arr id) <<< ((|(arr id) ((returnA -< x))|))}

/tmp/T.hs:12:14:
    The type of the first argument of a command form has the wrong shape
      Argument type: t_tG
    In the command: (arr id) <<< ((|(arr id) ((returnA -< x))|))
    In a stmt of a 'do' expression:
        x <- (arr id) <<< ((|(arr id) ((returnA -< x))|))
    In the expression:
      proc x -> do { x <- (arr id) <<< ((|(arr id) ((returnA -< x))|));
                     returnA -< x }

/tmp/T.hs:16:14:
    The type of the first argument of a command form has the wrong shape
      Argument type: t_tq
    In the command: (arr id) <<< ((|(arr id) ((returnA -< 3))|))
    In a stmt of a 'do' expression:
        x <- (arr id) <<< ((|(arr id) ((returnA -< 3))|))
    In the expression:
      proc x -> do { x <- (arr id) <<< ((|(arr id) ((returnA -< 3))|));
                     returnA -< x }

/tmp/T.hs:19:18:
    The type of the first argument of a command form has the wrong shape
      Argument type: t_k
    In the command: (arr id) <<< ((|(arr id) ((returnA -< 3))|))
    In the expression:
      proc x -> (arr id) <<< ((|(arr id) ((returnA -< 3))|))
    In an equation for `t'''':
        t''' = proc x -> (arr id) <<< ((|(arr id) ((returnA -< 3))|))
}}}
",peteg
5,2439,26,carter.schonwald@…,Missed optimisation with dictionaries and loops,Compiler,6.9,7.6.2,simonpj,new,lowest,2013-04-06T13:51:36-0700,"{{{
{-# LANGUAGE BangPatterns #-}
module Foo (sum') where

foldl' :: (a -> b -> a) -> a -> [b] -> a
{-# INLINE foldl' #-}
foldl' f !z xs = loop z xs
  where
    loop !z [] = z
    loop !z (x:xs) = loop (f z x) xs

sum' :: Num a => [a] -> a
sum' xs = foldl' (+) 0 xs
}}}

This is the code before !LiberateCase:

{{{
Foo.sum' =
  \ (@ a_a9T) ($dNum_aa1 [ALWAYS Just L] :: GHC.Num.Num a_a9T) ->
    let {
      lit_scm [ALWAYS Just L] :: a_a9T
      [Str: DmdType]
      lit_scm =
        case $dNum_aa1
        of tpl_B1 [ALWAYS Just A]
        { GHC.Num.:DNum tpl_B2 [ALWAYS Just A]
                        tpl_B3 [ALWAYS Just A]
                        tpl_B4 [ALWAYS Just A]
                        tpl_B5 [ALWAYS Just A]
                        tpl_B6 [ALWAYS Just A]
                        tpl_B7 [ALWAYS Just A]
                        tpl_B8 [ALWAYS Just A]
                        tpl_B9 [ALWAYS Just A]
                        tpl_Ba [ALWAYS Just C(S)] ->
        tpl_Ba lvl_sbH
        } } in
    letrec {
      loop_sck [ALWAYS LoopBreaker Nothing] :: a_a9T -> [a_a9T] -> a_a9T
      [Arity 2
       Str: DmdType SS]
      loop_sck =
        \ (z_a6Y :: a_a9T) (ds_db7 :: [a_a9T]) ->
          case z_a6Y of z_X7h [ALWAYS Just L] { __DEFAULT ->
          case ds_db7 of wild_B1 [ALWAYS Just A] {
            [] -> z_a6Y;
            : x_a72 [ALWAYS Just L] xs_a74 [ALWAYS Just S] ->
              case $dNum_aa1
              of tpl_Xl [ALWAYS Just A]
              { GHC.Num.:DNum tpl_B2 [ALWAYS Just A]
                              tpl_B3 [ALWAYS Just A]
                              tpl_B4 [ALWAYS Just C(C(S))]
                              tpl_B5 [ALWAYS Just A]
                              tpl_B6 [ALWAYS Just A]
                              tpl_B7 [ALWAYS Just A]
                              tpl_B8 [ALWAYS Just A]
                              tpl_B9 [ALWAYS Just A]
                              tpl_Ba [ALWAYS Just A] ->
              loop_sck (tpl_B4 z_a6Y x_a72) xs_a74
              }
          }
          }; } in
    \ (xs_a76 :: [a_a9T]) -> loop_sck lit_scm xs_a76
}}}

Note that the Num dictionary is scrutinised in the loop even though sum' is actually strict in the dictionary (by virtue of being strict in lit_scm) and it would make sense to take it apart before entering the loop. !LiberateCase does nail this but only if the loop is small enough and at the expense of code size.
",rl
5,2805,26,"pho@…, dterei",Test ffi009(ghci) fails on PPC Mac OS X,GHCi,6.11,7.6.2,,new,lowest,2012-09-12T04:14:04-0700,"The test ffi009(ghci) has failed for a while on PPC Msc OS X (http://darcs.haskell.org/buildbot/all/builders/tnaur%20PPC%20OSX%20head%202/builds/156/steps/runtestsuite/logs/unexpected):
{{{
=====> ffi009(ghci)
cd ./ffi/should_run && '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx-2/tnaur-ppc-osx-head-2/build/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin  -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci  -fglasgow-exts <ffi009.genscript 1>ffi009.interp.stdout 2>ffi009.interp.stderr
/bin/sh: line 1: 98633 Illegal instruction     '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx-2/tnaur-ppc-osx-head-2/build/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts < ffi009.genscript > ffi009.interp.stdout 2> ffi009.interp.stderr
Wrong exit code (expected 0 , actual 132 )
Stdout:
Testing 5 Int arguments...
True
True
True
True
True
True
True
True
True
True
Testing 11 Double arguments...

Stderr:

*** unexpected failure for ffi009(ghci)
}}}
An extract from the so-called crash report indicates a jump into the wild:
{{{
Exception Type:  EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000002, 0x00000000027ffd04
Crashed Thread:  2
...
Thread 2 Crashed:
0   ???                                 0x027ffd04 0 + 41942276
1   ghc                                 0x012da320 setThreadLocalVar + 16
2   ghc                                 0x012fa87c ffi_call_DARWIN + 204 (darwin.S:131)
3   ghc                                 0x012fa3a0 ffi_call + 208 (ffi_darwin.c:457)
4   ghc                                 0x012cacb8 interpretBCO + 4984
5   ghc                                 0x012d46d0 schedule + 1024
6   ghc                                 0x012d4d84 workerStart + 84
7   libSystem.B.dylib                   0x9292f658 _pthread_start + 316
}}}
When the test is run with a ghc built with {{{GhcDebugged=YES}}} (see http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking and {{{mk/config.mk}}}), an assertion failure is reported instead:
{{{
=====> ffi009(ghci)
cd . && '/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-and-copying-20070713_1212/ghc/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin  -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci  -fglasgow-exts <ffi009.genscript 1>ffi009.interp.stdout 2>ffi009.interp.stderr
/bin/sh: line 1: 43988 Abort trap              '/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-and-copying-20070713_1212/ghc/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts < ffi009.genscript > ffi009.interp.stdout 2> ffi009.interp.stderr
Wrong exit code (expected 0 , actual 134 )
Stdout:

Stderr:
ffi009: internal error: ASSERTION FAILED: file Linker.c, line 4380

    (GHC version 6.11.20081121 for powerpc_apple_darwin)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

*** unexpected failure for ffi009(ghci)
}}}
The assertion failure is reported from this context in {{{Linker.c}}}:
{{{
                    if(reloc->r_pcrel)
                    {
#ifdef powerpc_HOST_ARCH
                            // In the .o file, this should be a relative jump to NULL
                            // and we'll change it to a relative jump to the symbol
                        ASSERT(word + reloc->r_address == 0);
                        jumpIsland = (unsigned long)
                                        &makeSymbolExtra(oc,
                                                         reloc->r_symbolnum,
                                                         (unsigned long) symbolAddress)
                                         -> jumpIsland;
                        if(jumpIsland != 0)
                        {
                            offsetToJumpIsland = word + jumpIsland
                                - (((long)image) + sect->offset - sect->addr);
                        }
#endif
                        word += (unsigned long) symbolAddress
                                - (((long)image) + sect->offset - sect->addr);
                    }
}}}
The relocations leading to the assertion failure are required by branch instructions generated by {{{gcc}}} for {{{ffi009_stub.c}}} that contains expressions of the form {{{symbol+constant}}} (where {{{symbol}}} is an external symbol) whose distance to the instruction needs to be packed into a 24-bit field. An example is
{{{
        bl saveFP+56 ; save f28-f31
}}}
and there are actually 4 cases like this in the code generated by {{{gcc}}} for {{{ffi009_stub.c}}}.

This problem does not appear particularly easy to solve: The mechanism used when such a branch needs to address code that cannot be addressed using a 24-bit relative address is to create so-called jump islands, which are small, close-by pieces of code that (hopefully, but see #1845) *can* be reached using 24-bit relative addressing. The branch is changed to address the jump island which, in turn, constructs the actual 32-bit address and branches to it. Currently, however, this mechanism, for the PPC Mac OS X architecture, is limited to a single jump island per external symbol and is not capable of handling the addressing of external symbols with constants added to them. Handling the adding of a constant is doable, I believe, but the problem is that the same external symbol may appear multiple times with different constants added. For example, in addition to the above case, the code for {{{ffi009_stub.c}}} also includes
{{{
        bl saveFP+28 ; save f21-f31
}}}
which would require creating two jump islands for the single symbol {{{saveFP}}}.

Possible solutions:

 1. Make a special case out of the specific symbols concerned here. This would involve creating a limited list of different jump islands for these symbols, to be used when different constants were added.
 1. Generalize, somehow, the present jump island mechanism to allow more flexibility. It is undoubtably possible to do this, but it does not seem to be particularly easy to do.
 1. The {{{-mlongjump}}} option actually causes {{{gcc}}} to replace the critical relative brach instructions by inline code, at the expense of generating longer and potentially slower code for all calls and possibly other branches as well. And if we try this, we get:
{{{
ffi009: internal error: 
unknown relocation 13
    (GHC version 6.11.20081121 for powerpc_apple_darwin)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}
 (relocation type 13 is PPC_RELOC_JBSR) so Linker.c needs to be extended to handle this type also.

Any advice on how to proceed in this matter, additional ideas and views, would be most welcome.

Best regards
Thorkil",thorkilnaur
5,3123,26,batterseapower@…,make INLINE work for recursive definitions (generalized loop peeling/loop unrolling),Compiler,6.11,7.6.2,,new,lowest,2012-09-12T04:14:09-0700,"Inlining refers to the unfolding of definitions, ie replacing uses of identifiers with the definitions bound to them. Doing this at compile time can expose potential for other optimizations. As described in the User Guide, this is currently limited to non-recursive definitions, to avoid non-terminating recursion in the inliner. 
Unfolding Recursions

Since many definitions in non-trivial programs are either recursive themselves or are built from recursion combinators, leaving recursion out of inlining alltogether is a serious limitation, especially in view of the encoding of loops via tail recursion. In conventional languages, loop transformations such as loop unrolling are at the heart of optimizing high performance code (for a useful overview, see Compiler Transformations for High-Performance Computing, ACM Computing Surveys, 1994). As a consequence, many performance-critical Haskell programs contain hand-unrolled and hand-peeled recursions, which is error-prone and obscures declarative contents.

More details, examples, and an informal spec: wiki:Inlining",claus
5,17,26,mboes@…,Separate warnings for unused local and top-level bindings,Compiler,None,_|_,,new,lowest,2009-11-20T13:31:57-0800,"{{{
I'd like separate warnings for local and top-level
unused binds.  I often have ""unused"" top-level
functions which I use from ghci.  I'd like to avoid
warnings for
these while retaining the warnings for unused local
bindings (which can always be eliminated by prefix the
name with an underscore.)


}}}",magunter
3,7367,25,wasserman.louis@…,Optimiser / Linker Problem on amd64,Build System,7.6.1,7.8.1,,new,normal,2013-04-12T09:57:53-0700,"
The Haskell fannkuchredux contribution of Louis Wasserman to ""The Computer Language Benchmarks Game"" at shootout.alioth.debian.org times out on the amd64 machines, but not on the i386. I can reproduce it on my Debian amd64 machine. 

It turns out that compiling without optimisation or with a simple -O produces a fast program, but with enourmously large heap space allocated (10G compared with 67k on a virtual i386 machine) and also more garbage collector activity.

The source is below (because I don't find a way to attach the file). At the end  of the source I copied my make command line, run command line and output produced with option -sstderr.

---------------------


{{{
{-  The Computer Language Benchmarks Game
    http://shootout.alioth.debian.org/
    contributed by Louis Wasserman
    
    This should be compiled with:
    	-threaded -O2 -fexcess-precision -fasm
    and run with:
    	+RTS -N<number of cores> -RTS <input>
-}

import Control.Concurrent
import Control.Monad
import System.Environment
import Foreign hiding (rotate)
import Data.Monoid

type Perm = Ptr Word8

data F = F {-# UNPACK #-} !Int {-# UNPACK #-} !Int

instance Monoid F where
	mempty = F 0 0
	F s1 m1 `mappend` F s2 m2 = F (s1 + s2) (max m1 m2)

incPtr = (`advancePtr` 1)
decPtr = (`advancePtr` (-1))

flop :: Int -> Perm -> IO ()
flop k xs = flopp xs (xs `advancePtr` k)
 where flopp i j = when (i < j) $ swap i j >> flopp (incPtr i) (decPtr j)
       swap i j = do
	a <- peek i
	b <- peek j
	poke j a
	poke i b

flopS :: Perm -> (Int -> IO a) -> IO a
flopS !xs f = do
	let go !acc = do
		k <- peekElemOff xs 0
		if k == 0 then f acc else flop (fromIntegral k) xs >> go (acc+1)
	go 0

increment :: Ptr Word8 -> Ptr Word8 -> IO ()
increment !p !ct = do
	first <- peekElemOff p 1
	pokeElemOff p 1 =<< peekElemOff p 0
	pokeElemOff p 0 first
	
	let go !i !first = do
		ci <- peekElemOff ct i
		if fromIntegral ci < i then pokeElemOff ct i (ci+1) else do
			pokeElemOff ct i 0
			let !i' = i + 1
			moveArray p (incPtr p) i'
			pokeElemOff p i' first
			go i' =<< peekElemOff p 0
	go 1 first  

genPermutations :: Int -> Int -> Int -> Ptr Word8 -> Ptr Word8 -> IO F
genPermutations !n !l !r !perm !count = allocaArray n $ \ destF -> do
	let upd j !f run = do
		p0 <- peekElemOff perm 0
		if p0 == 0 then increment perm count >> run f else do
			copyArray destF perm n
			increment perm count
			flopS destF $ \ flops -> 
				run (f `mappend` F (checksum j flops) flops)
	let go j !f = if j >= r then return f else upd j f (go (j+1))
	go l mempty
 where checksum i f = if i .&. 1 == 0 then f else -f

facts :: [Int]
facts = scanl (*) 1 [1..12]

unrank :: Int -> Int -> (Ptr Word8 -> Ptr Word8 -> IO a) -> IO a
unrank !idx !n f = allocaArray n $ \ p -> allocaArray n $ \ count ->
  allocaArray n $ \ pp -> do
	mapM_ (\ i -> pokeElemOff p i (fromIntegral i)) [0..n-1]
	let go i !idx = when (i >= 0) $ do
		let fi = facts !! i
		let (q, r) = idx `quotRem` fi
		pokeElemOff count i (fromIntegral q)
		copyArray pp p (i+1)
		let go' j = when (j <= i) $ do
			let jq = j + q
			pokeElemOff p j =<< peekElemOff pp (if jq <= i then jq else jq - i - 1)
			go' (j+1)
		go' 0
		go (i-1) r
	go (n-1) idx
	f p count

main = do
   n <- fmap (read.head) getArgs
   let fact = product [1..n]
   let bk = fact `quot` 4
   vars <- forM [0,bk..fact-1] $ \ ix -> do
   	var <- newEmptyMVar
   	forkIO (unrank ix n $ \ p -> genPermutations n ix (min fact (ix + bk)) p >=> putMVar var)
   	return var
   F chksm mflops <- liftM mconcat (mapM takeMVar vars)
   putStrLn $ (show chksm) ++ ""\nPfannkuchen("" ++ (show n) ++ "") = "" ++ (show $ mflops)


{-

wurmli@noah-nofen:~/hpw/haskell/work/fannkuch$ ghc  --make
 -XBangPatterns -O -threaded -fllvm -rtsopts fannkuchredux.ghc-3.hs 
[1 of 1] Compiling Main             ( fannkuchredux.ghc-3.hs, fannkuchredux.ghc-3.o )
Linking fannkuchredux.ghc-3 ...
wurmli@noah-nofen:~/hpw/haskell/work/fannkuch$ ./fannkuchredux.ghc-3 +RTS -N4 -sstderr   -RTS 12
3968050
Pfannkuchen(12) = 65
  10,538,122,952 bytes allocated in the heap
         359,512 bytes copied during GC
          47,184 bytes maximum residency (2 sample(s))
          51,120 bytes maximum slop
               4 MB total memory in use (1 MB lost due to fragmentation)

                                    Tot time (elapsed)  Avg pause  Max pause
  Gen  0      6053 colls,  6053 par    0.16s    0.04s     0.0000s    0.0001s
  Gen  1         2 colls,     1 par    0.00s    0.00s     0.0001s    0.0001s

  Parallel GC work balance: 40.82% (serial 0%, perfect 100%)

  TASKS: 6 (1 bound, 5 peak workers (5 total), using -N4)

  SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)

  INIT    time    0.00s  (  0.00s elapsed)
  MUT     time   44.73s  ( 11.51s elapsed)
  GC      time    0.16s  (  0.04s elapsed)
  EXIT    time    0.00s  (  0.00s elapsed)
  Total   time   44.89s  ( 11.55s elapsed)

  Alloc rate    235,589,887 bytes per MUT second

  Productivity  99.6% of total user, 387.3% of total elapsed

gc_alloc_block_sync: 31024
whitehole_spin: 0
gen[0].sync: 0
gen[1].sync: 0

-}
}}}
",wurmli
3,7774,25,mainland@…,T5313 fails,GHC API,7.7,7.8.1,,new,normal,2013-05-29T08:05:22-0700,"T5313 fails
{{{
=====> T5313(normal) 76 of 104 [0, 0, 0]
cd . && '/home/ian/ghc/git/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o T5313 T5313.hs  -package ghc  >T5313.comp.stderr 2>&1
cd . && ./T5313 ""/home/ian/ghc/git/ghc/inplace/lib""   </dev/null >T5313.run.stdout 2>T5313.run.stderr
Wrong exit code (expected 0 , actual 1 )
Stdout:

Stderr:
T5313: <command line>: can't load .so/.DLL for: /home/ian/ghc/git/ghc/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.7.20130316.so (/home/ian/ghc/git/ghc/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.7.20130316.so: undefined symbol: stg_newByteArrayzh)

*** unexpected failure for T5313(normal)
}}}
",igloo
3,457,25,michal.terepeta@…,Strictness problem,Compiler,6.4.1,_|_,,new,normal,2010-10-16T12:38:22-0700,"{{{
As requested, this is a resubmission (and update) of a
previously reported bug, to get it into the bug tracker.

The following program should output something involving
Correct:

> module Main where

> f x = case x of
>   x@True  -> \y -> x && y
>   x@False -> \y -> x && y

> main = putStrLn $ f (error ""Correct"") `seq` ""Error""

However, whether it does so is a non-trivial function
of the GHC version and optimisation settings:

GHC version     -O2?  Correct?
------------------------------
4.08.1          No    Yes
4.08.1          Yes   No
5.04.2          No    No
5.04.2          Yes   Yes
6.0.1           _     No
6.2.2           _     No
6.4             _     No
6.4.1.20050820  _     No

All tests were run on a Solaris system.

Different fs give different behaviour, at least for
6.0.1. Try e.g.

> f x = case x of
>   True  -> id
>   False -> id

}}}",nilsanders
3,2280,25,ghc@…,randomR too slow,libraries/random,6.8.2,_|_,rrnewton,new,normal,2013-01-27T10:02:55-0800,"randomR is considerably slower than implementing it manually. Maybe I have not re-implemented it precisely, maybe it is just not inlined.

{{{
module Main (main) where

import System.Random (RandomGen(..), randomR, )
import qualified Data.ByteString as B

newtype KnuthRandomGen = KnuthRandomGen Int

{-# INLINE knuthFactor #-}
knuthFactor :: Int
knuthFactor = 40692

{-# INLINE knuthModulus #-}
knuthModulus :: Int
knuthModulus = 2^(31::Int)-249

-- we have to split the 32 bit integer in order to avoid overflow on multiplication
knuthSplit :: Int
knuthSplit = succ $ div knuthModulus knuthFactor

knuthSplitRem :: Int
knuthSplitRem = knuthSplit * knuthFactor - knuthModulus

instance RandomGen KnuthRandomGen where
   {-# INLINE next #-}
   next (KnuthRandomGen s) =
      -- efficient computation of @mod (s*knuthFactor) knuthModulus@ without Integer
      let (sHigh, sLow) = divMod s knuthSplit
      in  (s, KnuthRandomGen $ flip mod knuthModulus $
                   knuthSplitRem*sHigh + knuthFactor*sLow)
   {-# INLINE split #-}
   split (KnuthRandomGen s) =
      (KnuthRandomGen (s*s), KnuthRandomGen (13+s))
   {-# INLINE genRange #-}
   genRange _ = (1, pred knuthModulus)


main :: IO ()
main =
   do 
      -- for comparison: that's very fast
      putStrLn ""constant""
      B.writeFile ""random.out"" $ fst $
          B.unfoldrN 10000000
             (\g0@(KnuthRandomGen s) -> Just (fromIntegral s, g0))
             (KnuthRandomGen 1)

      -- 3 seconds on my machine
      putStrLn ""immediate""
      B.writeFile ""random.out"" $ fst $
          B.unfoldrN 10000000
             (\g0 -> let (w,g1) = next g0
                     in  Just (fromIntegral (mod w 256), g1))
             (KnuthRandomGen 1)

      -- 10 seconds on my machine
      putStrLn ""randomR""
      B.writeFile ""random.out"" $ fst $
          B.unfoldrN 10000000
             (\g0 -> Just (let (w,g1) = randomR (0,255) g0
                           in  (fromIntegral (w::Int), g1)))
             (KnuthRandomGen 1)


{-
ghc -o dist/build/randomtest -O -Wall -package bytestring-0.9.0.5 -ddump-simpl-iterations speedtest/RandomTest.hs
-}
{-
bytestring-0.9.0.1 as shipped with GHC-6.8.2 does not inline Data.ByteString.unfoldrN
-}

}}}

Is this related to Ticket 427?
",guest
3,1273,25,Bulat.Ziganshin@…,would like to print partial application values when at a breakpoint,GHCi,6.7,_|_,,new,normal,2008-09-30T08:51:16-0700,I'd like to be able to examine partial application values when at a breakpoint.,guest
4,4959,25,ghc@…,Warning about variables with leading underscore that are used anyway,Compiler (Parser),7.0.1,7.6.2,,new,low,2012-09-12T04:13:25-0700,"I use -Wall all the time, which includes -fwarn-unused-binds and -fwarn-unused-matches that warn about variable bindings that are not used. It already spotted lots of mistakes for me. You can suppress the warning by prepending an underscore '_' to a variable name. However, I have recently seen code, where variable names with leading underscores are regularly used, where other programmers might have chosen trailing underscores or primes. I suspect that the programmer was not aware, that he disabled warnings about unused bindings this way. Thus I like to have a warning about underscored variables that are used in the sense of the definition given for -fwarn-unused-binds in http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html.
We still have to decide whether this warning should be part of -Wall or -fwarn-unused-binds or whether there should be a separate option like -fwarn-used-underscored-binds.
",Lemming
4,4980,25,ghc@…,Warning about module abbreviation clashes,Compiler,7.0.1,7.6.2,,new,low,2012-09-12T04:13:25-0700,"Please add the option -fwarn-module-rename-collision that makes GHC to do the following: If GHC encounters an import situation like
{{{
module Main where

import qualified Data.A as A
import qualified Control.A as A
}}}
then GHC should emit a warning like
{{{
Main.hs:3:0:
Main.hs:4:0:
    Warning: Both Data.A and Control.A are renamed to A.
             An identifier like A.ident can only be resolved,
             if it is either in Data.A or Control.A.
             Better rename both modules to different names.
}}}

Reason for this warning is, that if 'ident' is from Data.A as of writing Main, and later another variable named 'ident' is added to Control.A, then A.ident can no longer be resolved in Main. That is, by accidental module rename collisions even qualified imports carry the risk of future name collisions.

Related to #4977
",Lemming
5,2075,25,andy.adamsmoran@…,hpc should render information about the run in its html markup,Code Coverage,6.8.2,7.6.2,andy@…,new,lowest,2013-01-26T17:28:11-0800,"To check if a generated coverage test is up to date, it would be useful to have hpc annotate its generated output with the date of the run, the compiler version, and OS info. Perhaps also information about which packages were included in the build.",dons
5,2168,25,"claus, pho@…",ghci should show haddock comments for identifier,GHCi,6.8.2,7.6.2,,new,lowest,2012-09-12T04:13:55-0700,"This came up in comp.lang.haskell recently:
http://groups.google.com/group/comp.lang.haskell/msg/ae69f720377e7a3f

I like the idea.

Immediate thoughts:
 * if ghci reads the source file, it can read haddock annotations
 * if ghci reads the interface file only (for library modules),
   it needs to find the installed documentation

On the other hand the requested feature is a typical IDE functionality
(cf. Eclipse/show source/show javadoc) and it's perhaps a bit much
to require that from ghci.

",j.waldmann
3,5630,24,"dterei, eventh@…",External Core needs love,Compiler,7.2.1,7.6.2,,new,normal,2012-09-12T04:12:06-0700,"{{{
{-# LANGUAGE GADTs #-}

data T a b where
  T1 :: a -> b -> T [a] (a,b)
  
main = putStrLn "":(""
}}}

and then ""ghc this.hs -fext-core""
results in

{{{
>ghc core-sandbox.hs -fext-core
ghc core-sandbox.hs -fext-core
[1 of 1] Compiling Main             ( core-sandbox.hs, core-sandbox.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.2.1 for i386-unknown-mingw32):
	make_exp (App _ (Coercion _))

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}
",quux
3,6087,24,stefan@…,Join points need strictness analysis,Compiler,7.4.1,7.6.2,,new,normal,2013-03-20T11:31:06-0700,"I came across this code in the `nofib/spectral` progam `knights`, in the code for `KnightHeuristic.possibleMoves`:
{{{
let {
  $j_sU3
    :: GHC.Types.Int -> GHC.Types.Int -> [KnightHeuristic.Direction]
  [LclId, Arity=2]
  $j_sU3 =
    \ (ww2_sRl :: GHC.Types.Int) (ww3_sRm :: GHC.Types.Int) ->
      case ww2_sRl of ww4_XQY { GHC.Types.I# ww5_sQU ->
      case GHC.Prim.>=# ww5_sQU 1 of _ {
        GHC.Types.False -> go1_azF ys_azM;
        GHC.Types.True ->
          case ds1_azR of _ { GHC.Types.I# y1_azp ->
          case GHC.Prim.<=# ww5_sQU y1_azp of _ {
            GHC.Types.False -> go1_azF ys_azM;
            GHC.Types.True ->
              case ww3_sRm of wild6_XAB { GHC.Types.I# x_XAE ->
              case GHC.Prim.>=# x_XAE 1 of _ {
                GHC.Types.False -> go1_azF ys_azM;
                GHC.Types.True ->
                  case GHC.Prim.<=# x_XAE y1_azp of _ {
                    GHC.Types.False -> go1_azF ys_azM;
                    GHC.Types.True ->
                      case GHC.List.notElem
                             @ ChessSetList.Tile
                             ChessSetList.isSquareFree_$dEq
                             (ww4_XQY, wild6_XAB)
                             wild2_azW
                      of _ {
                        GHC.Types.False -> go1_azF ys_azM;
                        GHC.Types.True ->
                          GHC.Types.:
                            @ KnightHeuristic.Direction y_azL (go1_azF ys_azM)
                      }
                  }
              }
              }
          }
          }
      }
      } } in
case y_azL of _ {
  KnightHeuristic.UL ->
    $j_sU3
      (case ww_sQJ of _ { GHC.Types.I# x_aya ->
       GHC.Types.I# (GHC.Prim.-# x_aya 1)
       })
      (case ww1_sQK of _ { GHC.Types.I# x_aya ->
       GHC.Types.I# (GHC.Prim.-# x_aya 2)
       });
  KnightHeuristic.UR ->
    $j_sU3
      (case ww_sQJ of _ { GHC.Types.I# x_ayl ->
       GHC.Types.I# (GHC.Prim.+# x_ayl 1)
       })
      (case ww1_sQK of _ { GHC.Types.I# x_aya ->
       GHC.Types.I# (GHC.Prim.-# x_aya 2)
       });

...lots more similar case alternatives follow...
}}}
Just look at all those `Int`s getting boxed, and the immediately unboxed by the join point!  The strictness analyser would spot this easily, but presumably the join point is constructed after strictness analysis.

There must be an opportunity here to run a later strictness analysis pass.",simonpj
3,5813,24,Christian.Maeder@…,Offer a compiler warning for failable pattern matches,Compiler,7.2.2,7.6.2,,new,normal,2012-09-12T04:12:09-0700,"This started off with a mailing list discussion: [http://www.mail-archive.com/haskell-cafe@haskell.org/msg96517.html]. The problem is that the following code produces no compile-time warning and results in a runtime error:


{{{
data MyType = Foo | Bar
    deriving Show

test :: Monad m => m MyType -> m ()
test myType = do
    Foo <- myType
    return ()

main :: IO ()
main = test $ return Bar
}}}

This is in contrast to the rest of pattern matching, which would warn about unmatched patterns, e.g.:

{{{
data MyType = Foo | Bar
    deriving Show

test :: Monad m => m MyType -> m ()
test myType = do
    x <- myType
    case x of
        Foo -> return ()

main :: IO ()
main = test $ return Bar
}}}

I understand that this style of code may be very useful in some circumstances when paired with a Monad providing a sensible fail implementation, and is especially used in list comprehensions. However, this is allowing an easily catchable static error to slip through our fingers.

I recommend we add a new compiler warning to catch incomplete patterns in do-notation binding. I believe this warning should not apply to list comprehensions. Ideally, this warning would be turned on by -Wall.",snoyberg
3,7186,24,iavor.diatchki@…,problems with typelits  and typenats,Compiler (Type checker),7.6.1-rc1,7.8.1,,new,normal,2012-10-30T10:38:43-0700,"in this test case
https://gist.github.com/3445419
in this case, the type errors seem to indicate SingI has two parameters,
but the documentation and the error free usage both point to one parameter


likewise in 
https://gist.github.com/3445456
the type checker can't seem to deduce that 1<=2
which should be ""trivial"" :)



",carter
3,7189,24,nathanhowell@…,RTS Assertion Crash,Runtime System,7.4.2,7.8.1,simonmar,new,normal,2012-10-16T11:50:12-0700,"I occasionally get the following crash when I compile with -debug:
{{{
internal error: ASSERTION FAILED: file rts/Schedule.c, line 1268

    (GHC version 7.4.2 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}
If the application is not compiled with -debug this does not seem to happen. Usually I just don't link in the debug runtime however I have been trying to rundown an IO that never completes. I can't post the app but I am happy to collect information to attach to this ticket.",sseverance
3,7794,24,mail@…,"GHCi ""Prelude.undefined"" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented",GHCi,7.6.2,7.8.1,,new,normal,2013-04-13T07:19:17-0700,"A number of non-trivial operations fail in ghci on ARM (specifically armhf on both Debian experimental and Ubuntu raring).  I initially noticed this as conduit's doctests failing, but reduced this to:
{{{
  $ ghci
  GHCi, version 7.6.2: 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> data Type a = Nothing
  *** Exception: Prelude.undefined
}}}
This is a singularly unhelpful exception, coming as it does without context, but I eventually tracked it down to ByteCodeItbls.mkJumpToAddr having no specific implementation for ARM and thus falling back to the default of ""undefined"".  I've tried adding this:
{{{
+#elif arm_TARGET_ARCH
+type ItblCode = Word32
+mkJumpToAddr a
+    = [ 0xe51ff004      -- ldr pc, [pc, #-4]    # pc reads as <current insn>+8
+      , fromIntegral (ptrToInt a) ]
}}}
This definitely changes the nature of the problem, so I think I'm on the right track, and I'm reasonably confident that that's the correct branch implementation; but when I actually try it in practice I get crashes (SIGSEGV/SIGILL/SIGBUS) with trashed stack traces, so I'm clearly not done yet.  Friends of mine suggest that I may need to `__clear_cache` or equivalent, which sounds plausible, so my current line of attack is figuring out how to glue that in; but if any actual GHC hackers can spot something obviously missing in the meantime then that would be great.",cjwatson
3,7459,24,nathanhowell@…,deriving Generic does not work with TypeLits,Compiler,7.6.1,7.8.1,dreixel,new,normal,2013-04-12T13:28:41-0700,"
{{{
{-# LANGUAGE DataKinds, KindSignatures #-}
{-# LANGUAGE DeriveGeneric #-}

import GHC.TypeLits
import GHC.Generics

data F (a :: Symbol)
data X = X (F ""hello"") deriving Generic
}}}

Trying to derive Generics instance for simple datatype with Symbol inside but GHC complains:

{{{
  Can't make a derived instance of `Generic X':
     X must not have unlifted or polymorphic arguments
   In the data declaration for `X'
}}}


I found that this could be fixed by adding single line to isTauTy:

{{{
--- a/compiler/typecheck/TcType.lhs
+++ b/compiler/typecheck/TcType.lhs
@@ -899,6 +899,7 @@ mkTcEqPred ty1 ty2
 isTauTy :: Type -> Bool
 isTauTy ty | Just ty' <- tcView ty = isTauTy ty'
 isTauTy (TyVarTy _)      = True
+isTauTy (LitTy _)        = True
 isTauTy (TyConApp tc tys) = all isTauTy tys && isTauTyCon tc
 isTauTy (AppTy a b)      = isTauTy a && isTauTy b
 isTauTy (FunTy a b)      = isTauTy a && isTauTy b
}}}
",maxtaldykin
3,7767,24,mail@…,"""internal error: evacuate: strange closure type 154886248"" crash",Runtime System,7.6.2,7.8.1,,new,normal,2013-04-13T06:20:49-0700,"I have a simple Main.hs that uses the GHC API to produce a '''ParsedModule'''. I then use ghc-vis this value, which is when I get:
{{{
Starting ...
Setting dynamic flags ...
Guessing and adding target ...
Analyze dependencies ...
Getting module summary ...
Parsing module ...
Main: internal error: evacuate: strange closure type 154886248
    (GHC version 7.6.2 for x86_64_apple_darwin)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
[1]    7583 abort      ./Main
}}}

Here is the Main.hs:
{{{

{-# LANGUAGE CPP #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE StandaloneDeriving #-}
{-# LANGUAGE RecordWildCards #-}

{-
See the following link for additional details about the API:
    http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/API
-}
module Main where

import Module
import RdrName
import OccName
import BasicTypes
--import Bag

--import HsDecls
--import Control.Monad
import Control.Exception (throw)
import GHC hiding (loadModule)
import SrcLoc
import MonadUtils
import GHC.Paths (libdir)
import HscTypes
--import DynFlags
import Unsafe.Coerce
--import Bag (bagToList)
--import Outputable
--import Name
import Data.Typeable
import Text.Show
import Data.Foldable(forM_)

import GHC.Exts
--import GHC.HeapView

import GHC.Vis

main :: IO ()
main = do
    doMain
    getLine
    return ()

--libdir = ""/Library/Frameworks/GHC.framework/Versions/7.6.2-x86_64/usr/lib""

doMain = do
    putStrLn ""Starting ...""
    runGhc (Just libdir) $ do
    -- 
    liftIO $ putStrLn ""Setting dynamic flags ...""
    dflags <- getSessionDynFlags
    setSessionDynFlags (dflags)

    --
    liftIO $ putStrLn ""Guessing and adding target ...""
    -- guessTarget :: GhcMonad m => String -> Maybe Phase -> m Target
    target <- guessTarget ""Test.hs"" Nothing
    -- addTarget :: GhcMonad m => Target -> m ()
    addTarget target

    --liftIO $ putStrLn ""Loading all targets ...""        
    --_ <- load (LoadUpTo modName)

    liftIO $ putStrLn ""Analyze dependencies ...""        
    -- depanal :: GhcMonad m =>
            --   [ModuleName]  -- ^ excluded modules
            -- -> Bool          -- ^ allow duplicate roots
            -- -> m ModuleGraph
    modGraph <- depanal [] False

    let modName = mkModuleName ""Test""
    liftIO $ putStrLn ""Getting module summary ...""
    -- getModSummary :: GhcMonad m => ModuleName -> m ModSummary
    modSummary <- getModSummary modName

    liftIO $ putStrLn ""Parsing module ...""
    --data ParsedModule = ParsedModule { pm_mod_summary   :: ModSummary
    --                                 , pm_parsed_source :: ParsedSource
    --                                 , pm_extra_src_files :: [FilePath] }
    -- type ParsedSource      = Located (HsModule RdrName)
    -- type Located e = GenLocated SrcSpan e
    -- parseModule :: GhcMonad m => ModSummary -> m ParsedModule
    parsedMod <- parseModule modSummary

    liftIO $ vis
    liftIO $ view parsedMod ""parsedMod""

    --let parsedSrc = pm_parsed_source parsedMod
    ----walkLocSource parsedSrc

    ----typecheckModule :: GhcMonad m => ParsedModule -> m TypecheckedModule
    --liftIO $ putStrLn ""Type checking module ...""
    --typedMod <- typecheckModule parsedMod
    ----let parsedMod = tm_parsed_module typedMod
    ----walkLocSource (pm_parsed_source parsedMod)

    --let rnSource = tm_renamed_source typedMod
    ----walkRenamedSource rnSource

    ---- desugarModule :: GhcMonad m => TypecheckedModule -> m DesugaredModule
    --liftIO $ putStrLn ""Desugaring module ...""
    --desugaredMod <- desugarModule typedMod
    return ()
}}}

I have built it using:
{{{
ghc --make -L/usr/lib -package ghc Main.hs -threaded 
}}}
",rodlogic
3,1687,24,mihai.maruseac@…,A faster (^)-function.,Prelude,6.6.1,_|_,,new,normal,2013-01-26T14:29:30-0800,"This function performs better for me than the `(^)`-function in GHC. I seem to only be able to test it for the Integer type though and its only tested with ghc 6.6 (and ghc 6.6.1 by byorgey on #haskell).
I'm not sure if you really need this or if it is correct, but after discussion on #haskell i was asked to make a bug report so here it is! Enjoy. :)

{{{
module Pow (pow) where
import Prelude hiding ((^))
pow = (^)

(^) :: (Integral b, Num a) => a -> b -> a
x ^ y | y < 0     = error ""Negative exponent""
      | y == 0    = 1
      | y == 1    = x
      | odd y     = x * x^(y - 1)
      | otherwise = let x' = x^(y `div` 2) 
                    in x' * x'
}}}

Tests

{{{
-- TestData.hs
module TestData where
e = 10^8
}}}
{{{
-- mytest.hs
import Pow
import TestData
main = print $ (2 `pow` e) `mod` 2
}}}
{{{
-- ghctest.hs
import TestData
main = print $ (2 ^ e) `mod` 2
}}}

Test results (performance)
{{{
$ time ./ghctest
0

real    0m11.744s
user    0m11.449s
sys     0m0.104s

$ time ./mytest
0

real    0m6.794s
user    0m6.696s
sys     0m0.084s

-}
}}}

QuickCheck test
{{{
-- qc.hs
-- $ ./qc 
-- OK, passed 100 tests.

import Test.QuickCheck
import Pow

main = quickCheck prop 
prop x y = y >= 0 ==> x `pow` y == x^y
}}}",moonlite@…
3,3769,24,mail@…,Add manpages for programs installed alongside ghc,Documentation,6.12.1,_|_,,new,normal,2012-10-02T15:56:01-0700,"The following programs installed with GHC (specifically, using the Mac OS X installer, though I suspect this applies to all platforms) do not have manpages:

 * `ghc-pkg`
 * `ghci` (Technically, its manpage is the same as `ghc`'s, but there's no `ghci.1` symlink to `ghc.1`, so `man ghci` fails to find anything.)
 * `haddock`
 * `hp2ps`
 * `hpc`
 * `hsc2hs`
 * `runghc`
 * `runhaskell`

I think that's all of them.

I realize that not all of these programs (e.g., `haddock`) are truly part of GHC, but the ones that are still need manpages.  If the problem is that writing *roff is hard, and you don't mind mooching off other languages, might I refer you to [http://perldoc.perl.org/perlpod.html POD]/[http://perldoc.perl.org/pod2man.html pod2man]?",Minimiscience
4,5197,24,nathanhowell@…,Support static linker semantics for archives and weak symbols,Runtime System,7.0.3,7.6.2,,new,low,2012-09-12T04:13:29-0700,"While looking at #5004, I had a go at getting the GHCi linker to load the LLVM libs, as in making this work: `ghci -package llvm`.

This involves loading a whole bunch of LLVM*.a files and linking them against the C and C++ standard libs. This in turn requires a few more features in the GHCi linker:

 * support for weak symbols
 * search archives only on demand
 * support .oS files in archives

The last is trivial.

The first is not so hard to do. When the linker finds a definition of a weak symbol, if there's already a symbol with that name in the symbol table then we just ignore the new one. When resolving symbols if we find an unresolved weak symbol we just give it the value zero. Doing this is enough to load .e.g libstdc++.a and libc.a (rather than libc.so).

The next part is a bit more work. When you give system static linker some .a files, it only uses them to provide definitions for unresolved symbols in the main target. In particular it is fine for two .a files to provide definitions of the same symbol because the linker just looks for the first. (This is in contrast to duplicate symbols in the main .o input files). On linux, both libm and libc define some of the same symbols, such as `__isinf`.

Similarly, there is a problem that the GHCi linker predefines the `atexit` symbol, but that is also defined by `libc.a`.

So for the GHCi linker to load both libm and libc then it has to follow the standard semantics for linking archives. Currently it treats an archive as a request to link all the .o files in that archive.

Probably it is not sensible to go as far as implementing the full standard static linking semantics in the GHCi linker. It's of somewhat questionable value since we mainly need it for linking Haskell code, not C/C++ code.

Nevertheless, if we do need this, then the attached Linker.c has a partial implementation. It does the weak symbols and `.oS` files in archives.",duncan
4,3713,24,"dankna@…, dterei",Track -dynamic/-fPIC to avoid obscure linker errors,Compiler,6.10.4,7.6.2,,new,low,2012-09-12T04:12:19-0700,"Using the wrong combination of `-dynamic` and/or `-fPIC` can lead to obscure linker errors, see e.g. #3705.  We should track whether an object file was compiled with `-dynamic` and `-fPIC` so that we can give better error messages before running the linker.

'''See also'''
[[TicketQuery(id=3712|)]]",simonmar
4,1201,24,alfonso.acosta@…,ghci runs Template Haskell splices 4 times,Template Haskell,6.6,_|_,simonpj,new,low,2013-01-22T09:26:05-0800,"ghci (both 6.6 and HEAD) appears to run Template Haskell splices 4 times, as shown here:
{{{
$ ghci -fth -v0
Prelude> :m + Language.Haskell.TH
Prelude Language.Haskell.TH> $(do runIO $ (Random.randomIO :: IO Int) >>= print; [| 1 |] )
7184082642420483628
-8222359774145102883
2625059211496099566
1462332877512834399
1
}}}",igloo
4,4463,24,choener@…,CORE notes break optimisation,Compiler,7.1,_|_,,new,low,2010-11-17T03:22:49-0800,"I think at some point we decided that Core notes shouldn't affect optimisation. Here is a case where they do:

{{{
module Foo where

foo :: Int -> Int
{-# INLINE [1] foo #-}
foo x = x+1

{-# RULES ""foo/foo"" forall x. foo (foo x) = x #-}
}}}

{{{
module Bar where

import Foo

bar :: Int -> Int -> Int
bar x y = foo ({-# CORE ""note"" #-} x `seq` foo y)
}}}

When compiled with -O2, the rule doesn't fire with the note but does fire without it. This is the Core with the note:

{{{
Bar.bar =
  \ (x_aaw :: GHC.Types.Int) (y_aax :: GHC.Types.Int) ->
    Foo.foo
      (__core_note ""note""
       (case x_aaw of _ { GHC.Types.I# _ -> Foo.foo y_aax }))
}}}

For the rule to fire, GHC must move the seq to the outside but because of the note, it doesn't.",rl
3,7958,23,fuuzetsu@…,'Cannot continue after interface file error' during compilation,Compiler,7.7,,,new,normal,2013-06-03T17:08:32-0700,"I'm trying to compile [http://hackage.haskell.org/package/test-framework-hunit `test-framework-hunit-0.3.0`] library using HEAD. Running these commands:

{{{
ghc Setup.lhs && \
./Setup configure --user --enable-shared && \
./Setup build && ./Setup install
}}}

gives me this error:

{{{
Installing package test-framework-hunit-0.3.0
[1 of 1] Compiling Main             ( Setup.lhs, Setup.o )
Linking Setup ...
Configuring test-framework-hunit-0.3.0...
Building test-framework-hunit-0.3.0...
Preprocessing library test-framework-hunit-0.3.0...
[1 of 1] Compiling Test.Framework.Providers.HUnit ( Test/Framework/Providers/HUnit.hs, dist/build/Test/Framework/Providers/HUnit.o )
/home/killy/.cabal/lib/x86_64-linux-ghc-7.7.20130602/test-framework-0.8/Test/Framework/Core.hi
Declaration for Test
Constructor Test.Framework.Core.Test:
  Iface type variable out of scope:  i
Cannot continue after interface file error
}}}

This error refers to `test-framework-0.8`, which is a previously installed library (also compiled with HEAD) that `test-framework-hunit` depends on. This didn't happen on HEAD 12 days ago, so I think it must be some recent change that broke this.",jstolarek
3,2595,23,noah.easterly@…,Implement record update for existential and GADT data types,Compiler,6.8.3,6.12 branch,,new,normal,2011-01-07T04:27:22-0800,"Ganesh writes: The most important thing for me is supporting record update for
existentially quantified data records, as in the error below.

In general I also find working with code that involves existential
type variables quite hard work - for example I can't use foo as a
record selector either, even if I immediately do something that seals
the existential type back up again.

I don't understand this stuff well enough to be sure whether it's an
impredicativity issue or not, though.

{{{
Foo.hs:11:8:
    Record update for the non-Haskell-98 data type `Foo' is not (yet)
supported
    Use pattern-matching instead
    In the expression: rec {foo = id}
    In the definition of `f': f rec = rec {foo = id}
}}}
Program is:
{{{
{-# LANGUAGE Rank2Types #-}
module Foo where

data Foo = forall a . Foo { foo :: a -> a, bar :: Int }

x :: Foo
x = Foo { foo = id, bar = 3 }

f :: Foo -> Foo
f rec = rec { foo = id }

g :: Foo -> Foo
g rec = rec { bar = 3 }
}}}

Simon says: Ah now I see.  The relevant comment, `TcExpr` line 465, says
{{{
-- Doing record updates on
-- GADTs and/or existentials is more than my tiny 
-- brain can cope with today
}}}
Should be fixable, even with a tiny brain.


",simonpj
3,5470,23,rleshchinskiy@…,The DPH library needs to support PData and PRepr instances for more than 15-tuples,Data Parallel Haskell,7.3,7.6.2,chak,new,normal,2012-09-12T04:12:04-0700,"Currently, `Data.Array.Parallel.PArray.PDataInstances` only generates tuple instances up to 6-tuple.  This is not sufficient as these instances are used for environments of closures by the vectoriser — i.e., once a closures has more than 15 free variables, the compiler fails with `VectMonad.lookupFamInst: not found`.

",chak
3,6149,23,karel.gardas@…,ghc-7.4.2 tests for profasm seg-fault under solaris,Compiler,7.4.2-rc1,7.8.1,,new,normal,2012-10-12T12:44:23-0700,"I've compiled http://www.haskell.org/ghc/dist/stable/dist/ghc-7.4.2-src.tar.bz2 from 05-Jun-2012 under x86 solaris.

The results of running the testsuite will be attached.
Can these failures be observed on kgardas-opensolaris-x86-head, too?
",maeder
3,7610,23,karel.gardas@…,Cross compilation support for LLVM backend,Compiler (LLVM),7.6.1,7.8.1,dterei,new,normal,2013-04-12T15:56:50-0700,"Top level bug to track supporting cross compilation in LLVM backend.

Mostly this shouldn't be too bad but I haven't tried it and know of at least a few significant issues.",dterei
5,1693,23,claus.reinke@…,Make distclean (still) doesn't,Build System,6.6.1,7.6.2,igloo,new,lowest,2013-01-28T02:15:27-0800,"There are various ways in which `make distclean` does not remove all the files it should.  Please keep adding to this bug description as you find more.

The following things are not currently distcleaned and should be, and hence are ending up in the source distribution:

{{{
libraries/haddock.css
libraries/haddock-util.js
}}}",simonpj
2,7325,22,johan.tibell@…,threadDelay mistreats minBound and maxBound in some configurations,Runtime System,7.6.1,7.6.2,,new,high,2012-10-22T08:11:49-0700,"threadDelay currently treats minBound and maxBound incorrectly in some cases.  This breaks the following idiom ([http://hackage.haskell.org/packages/archive/async/latest/doc/html/src/Control-Concurrent-Async.html#Concurrently as seen in the async package]):

{{{
forever (threadDelay maxBound)
}}}

On Linux (Ubuntu 10.04 64-bit) without -threaded, {{{threadDelay maxBound}}} returns immediately.  For lower numbers on the same order of magnitude, it behaves non-deterministically.  For example, given this program:

{{{
import Control.Concurrent
import Control.Monad

main = forM_ [6244222868950683224..] $ \i -> do
    print i
    threadDelay i
}}}

threadDelay returns immediately in some cases but not in others.  If I compile and run it in bash like this:

{{{
ghc-7.6.1 -fforce-recomp threadDelay-maxBound.hs ; ./threadDelay-maxBound
}}}

The bug usually appears, but if I run it like this:

{{{
ghc-7.6.1 -fforce-recomp threadDelay-maxBound.hs
./threadDelay-maxBound
}}}

The bug does not appear (threadDelay blocks like it should).  Thus, the program is affected by a very subtle difference in how it is invoked.  Perhaps it is sensitive to file descriptor numbers.

On Windows without -threaded, {{{threadDelay maxBound}}} seems to work, but {{{threadDelay minBound}}} blocks rather than returning immediately.",joeyadams
2,6017,22,peter.minten@…,Reading ./.ghci files raises security issues,GHCi,7.4.1,7.8.1,,new,high,2013-01-01T07:36:11-0800,"GHCi will execute .ghci files in the current directory, and this can be used to run arbitrary shell commands.

It seems to me that most people would not expect that running ""ghci"" in a directory can cause arbitrary commands to be executed. This could be a security issue, e.g. running ghci in a just downloaded software package with a rouge .ghci file.

Also it affects invocations ""ghc -e"", which conceivably could be used in aliases or scripts for some action unrelated to running a ghci session, as in http://www.joachim-breitner.de/blog/archives/156-Haskell-on-the-Command-Line.html

I just noticed that it will not read files in directories not owned by you and warn you about it (e.g. in /tmp), which is a good start. But this does not help against files in packaged repositories.

Maybe ghci could keep a white-list of files somewhere in ~/.ghci and ask if it should execute a .ghci file that has not been encountered before.

Alternatively (and more work) a safe subset of options (such as inclusion paths) could be identified and only those would be allowed in ./.ghci, while ~/.ghci allows all commands.",nomeata
3,7866,22,Artyom.Kazak@…,floor (0/0) :: Int is different with -O0 and -O1,Compiler,7.6.2,,,new,normal,2013-05-23T16:26:34-0700,"This program:
{{{
main = print (floor (0/0) :: Int)
}}}

prints a different result with -O0:
{{{
0
}}}
and -O1:
{{{
-9223372036854775808
}}}",alang9
3,5320,22,dimitris@…,check_overlap panic (7.1 regression),Compiler,7.1,7.6.2,simonpj,new,normal,2012-09-12T04:12:02-0700,"The attached program is rightfully rejected by GHC 7.0.4 (with {{{""Could not deduce (HMapClass f l) ...""}}}) but makes GHC HEAD panic:
{{{
$ ghc-7.3.20110713 Overlap.hs 
[1 of 1] Compiling Overlap          ( Overlap.hs, Overlap.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.3.20110713 for x86_64-unknown-linux):
	check_overlap
    main:Overlap.HDropClass{tc raS}
      main:Overlap.PZero{tc raZ}
      (main:Overlap.HMap{tc raN} f{tv adi} [sk] l{tv adk} [sk])

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

}}}
Both versions are built with the devel2 BuildFlavour.
",mikhail.vorozhtsov
3,5924,22,johan.tibell@…,Bad Cmm generated for updating one element in Array#,Compiler,7.4.1,7.6.2,,new,normal,2012-09-12T04:12:12-0700,"I've attached a small standalone program that implements the following function:

{{{
-- | /O(n)/ Update the element at the given position in this array.
update16 :: Array e -> Int -> e -> Array e
}}}

which update one element (by copying the whole array) of an array of size 16. The attachment includes the optimized Cmm for a call to this function, together with a bunch of comments (inline with the Cmm) by me, pointing out inefficiencies in the generated Cmm.

My overall goal is to make this particular function fast. This might involve fixes to the code generator and/or adding primitives whether that makes sense. In any case this code might be a good source of ideas for improvements to the code generator.

To follow my annotations, start at `Update.test_info` in `Update.cmm`.",tibbe
3,5364,22,johan.tibell@…,Access RTS flag values from inside Haskell programs,libraries/base,7.3,7.6.2,,new,normal,2012-09-12T04:12:02-0700,"Strictly speaking, it is already possible to do this since includes/rts/Flags.h exports RtsFlags, which can be accessed with a mini wrapper function. We should add this wrapper function so we can import it, and then write code which reads out the contents of all the various parameters so that users can introspect this at runtime. Maybe put them in the GHC.RTS module.",ezyang
3,5925,22,johan.tibell@…,Add inline version of newArray#,Compiler,7.4.1,7.6.2,,new,normal,2013-05-10T08:58:32-0700,"It'd would be nice to have an inline version of `newArray#` so that allocation of small arrays is cheaper (e.g. the heap check could be paired up with other heap checks.)

I see two possible designs:

 1. Add a branch to `newArray#` that checks the requested size and either allocates inline or out-of-line.
 2. Add a new primop e.g. `newSmallArray#` that always allocates inline.

I would lean towards (2). While (1) is equal to (2) in the case when the size is statically known (assuming that GHC can discover that fact through enough inlining at the Cmm level), there are cases where the programmer knows that the size is small, without knowing the exact size. This happens e.g. when you use arrays to represent small variable-length tuples (e.g. in the `unordered-containers` package.)",tibbe
3,7482,22,johan.tibell@…,GHC.Event overwrites main IO managers hooks to RTS,libraries/base,7.4.1,7.8.1,AndreasVoellmy,new,normal,2013-04-12T13:56:54-0700,"The IO manager registers two file descriptors with the RTS which the RTS uses to send control and wakeup signals to the IO manager. The main IO manager is started up by default and registers some file descriptors that it has allocated with the RTS.  

The base package also exposes a GHC.Event module which when initialized will also register files with the RTS, overwriting the main IO manager's files. Now the RTS can no longer signal the main IO manager.",AndreasVoellmy
3,1614,22,lennart@…,Type checker does not use functional dependency to avoid ambiguity,Compiler (Type checker),6.7,_|_,,new,normal,2013-01-27T06:46:24-0800,"Compiling the following module gives an error
{{{
module X where

class C a | -> a
instance C Int

unC :: (C a) => a -> Int
unC i = undefined

test :: Int
test = unC undefined
}}}
Error message:
{{{
X.hs:13:7:
    Ambiguous type variable `a' in the constraint:
      `C a' arising from a use of `unC' at X.hs:13:7-19
    Probable fix: add a type signature that fixes these type variable(s)
}}}

But that is just plain wrong.  The functional dependency in the definition of C forces a to be Int.  No other type is possible.  So what's ambiguous about that?",guest
4,4019,22,gracjanpolak@…,deriving Ord can produce incorrect and inefficient instances,Compiler,6.13,7.6.2,,new,low,2012-09-12T04:12:23-0700,"This bug was spotted by Barak Pearlmutter in http://www.haskell.org/pipermail/haskell-cafe/2010-April/076762.html.

{{{
data T = T Double deriving( Eq, Ord )

*Main> T (0/0) > T (0/0)
True
*Main> (0/0) > (0/0)
False
}}}

This happens because the derived Ord instance only defines compare and relies on default method definitions for everything else. Comparisons involving !NaNs always return False, however, compare (arbitrarily) returns GT in this case.

Irrespective of this particular wart, this is what GHC ultimately produces for (<=):

{{{
T.$fOrdT_$c<= =
  \ (x_ahF :: T.T) (y_ahG :: T.T) ->
    case x_ahF of _ { T.T a1_afL ->
    case y_ahG of _ { T.T b1_afM ->
    case a1_afL of _ { GHC.Types.I# x#_ah1 ->
    case b1_afM of _ { GHC.Types.I# y#_ah5 ->
    case GHC.Prim.<# x#_ah1 y#_ah5 of _ {
      GHC.Bool.False -> GHC.Prim.==# x#_ah1 y#_ah5;
      GHC.Bool.True -> GHC.Bool.True
    }
    }
    }
    }
    }
}}}

Note that the definition uses two comparisons even though (<=) for Double uses just one: (<=##). In general, relying on default method definitions when deriving Ord can be inefficient because the individual comparison operators might very well be faster than compare for the wrapped types.",rl
4,4296,22,dimitris@…,The dreaded SkolemOccurs problem,Compiler,6.12.3,7.6.2,simonpj,new,low,2012-09-12T04:12:29-0700,"The ""!SkolemOccurs"" problem is a celebrated difficulty with combining (a) termination and (b) completeness, in this example:
{{{
type instance F [a] = [F a]
f :: (F [a] ~ a) => ...
}}}
Currently we err on the side of completeness, and lose termination:
{{{
Simple20.hs:9:1:
    Context reduction stack overflow; size = 21
    Use -fcontext-stack=N to increase stack size to N
      co :: F [F (F (F (F (F (F (F (F (F (F a)))))))))]
              ~
            F (F (F (F (F (F (F (F (F (F a)))))))))
      co :: F (F (F (F (F (F (F (F (F a))))))))
              ~
            [F (F (F (F (F (F (F (F (F (F a)))))))))]
      co :: F [F (F (F (F (F (F (F (F (F a))))))))]
              ~
            F (F (F (F (F (F (F (F (F a))))))))
      co :: F (F (F (F (F (F (F (F a)))))))
              ~
            [F (F (F (F (F (F (F (F (F a))))))))]
      co :: F [F (F (F (F (F (F (F (F a)))))))]
              ~
            F (F (F (F (F (F (F (F a)))))))
      co :: F (F (F (F (F (F (F a))))))
              ~
            [F (F (F (F (F (F (F (F a)))))))]
      co :: F [F (F (F (F (F (F (F a))))))] ~ F (F (F (F (F (F (F a))))))
      co :: F (F (F (F (F (F a))))) ~ [F (F (F (F (F (F (F a))))))]
      co :: F [F (F (F (F (F (F a)))))] ~ F (F (F (F (F (F a)))))
      co :: F (F (F (F (F a)))) ~ [F (F (F (F (F (F a)))))]
      co :: F [F (F (F (F (F a))))] ~ F (F (F (F (F a))))
      co :: F (F (F (F a))) ~ [F (F (F (F (F a))))]
      co :: F [F (F (F (F a)))] ~ F (F (F (F a)))
      co :: F (F (F a)) ~ [F (F (F (F a)))]
      co :: F [F (F (F a))] ~ F (F (F a))
      co :: F (F a) ~ [F (F (F a))]
      co :: F [F (F a)] ~ F (F a)
      co :: F a ~ [F (F a)]
      co :: F [F a] ~ F a
      co :: a ~ [F a]
      co :: F [a] ~ a
}}}
",simonpj
4,4301,22,michal.palka@…,Optimisations give bad core for foldl' (flip seq) (),Compiler,6.12.3,7.6.2,,new,low,2012-09-12T04:12:30-0700,"I'm not sure whether it's one freak case or a symptom of a problem that occurs more often. Compiled with optimisations, the code
{{{
foo :: [a] -> ()
foo = foldl' (flip seq) ()
}}}
produces the core
{{{
Rec {
FSeq.foo1 :: forall a_af0. [a_af0] -> (##)
GblId
[Arity 1
 NoCafRefs
 Str: DmdType S]
FSeq.foo1 =
  \ (@ a_af0) (w_sg9 :: [a_af0]) ->
    case case w_sg9 of _ {
           [] -> GHC.Unit.();
           : x_afz xs_afA ->
             case x_afz of _ { __DEFAULT ->
             case FSeq.foo1 @ a_af0 xs_afA of _ { (# #) -> GHC.Unit.() }
             }
         }
    of _ { () ->
    GHC.Prim.(##)
    }
end Rec }
}}}
for the worker (ghc-6.12.3, similar core from HEAD). Due to the boxing and unboxing between (##) and (), there's a case on the recursive call, hence it produces a stack overflow on long enough lists.

The problem was reported in http://www.haskell.org/pipermail/beginners/2010-September/005287.html, my attempt at understanding it here: http://www.haskell.org/pipermail/beginners/2010-September/005293.html.

So far, I've only managed to produce it for the very special combination of foldl' (flip seq) and a single (non-bottom) value datatype; any other function to be folded or a multiple value type produce a tail-recursive two-argument worker.

Nevertheless, on the off chance that it's a symptom of a real problem, I'm reporting it.",daniel.is.fischer
4,4899,22,ppremont@…,"Non-standard compile plus Template Haskell produces spurious ""unknown symbol"" linker error",Compiler,7.0.1,7.6.2,simonmar,new,low,2012-09-12T04:13:23-0700,"Programs that use Template Haskell fail to link when doing a ""non-standard"" compile. Specifically, compilations with -prof and -dynamic produce this bug, although other flags may as well; it seems that compilations that require the two-stage -osuf flag produce this bug. The error message is always ""unknown symbol"" but the specific symbol that is allegedly missing varies. Removing the TH block from the code makes the problem go away.

I've provided a minimal example of a program that can reproduce this bug, in the enclosed files Bug1.hs and Main.hs. A typescript demonstrating the error message is also included.

Tested on GHC 7.0.1 and 6.12.1, running under Ubuntu 10.04, both 64-bit and 32-bit. Also tested with 6.12.3 under 32-bit Windows 7.",jepst
4,5262,22,michal.palka@…,Compiling with -O makes some expressions too lazy and causes space leaks,Compiler,7.1,7.6.2,,new,low,2012-09-12T04:13:30-0700,"Here are some expressions that are executed in a too lazy way when optimisation is turned on in GHC. GHC is known to make some expressions too lazy when full laziness is turned on (as in #917), and indeed some of these expressions execute correctly when you add -fno-full-laziness. However, some of them are compiled too lazy even if -fno-full-laziness is present.

Here are terms that get compiled too lazy with -O only when full strictness is on:
{{{
seq (id (\a -> seq a (\b -> (undefined::Int))) (undefined::Bool))
\a -> seq (seq a (\b -> seq b null) (undefined::([] ([] Int)) -> [] Int)) (\b -> ([]::[] Int)) length
\a -> seq (id (\b -> seq b (\c -> seq)) (length a)) ([]::[] Int)
}}}

Here are terms which are compiled too lazy with -O regardless of full strictness:
{{{
seq (seq (odd (undefined::Int)) (\a -> (undefined::[] (Int -> Bool))))
foldr (\a -> seq) id ((:) True (undefined::[] Bool))
\a -> foldr (\b -> \c -> seq c (\d -> ([]::[] Int))) (undefined::Bool -> [] Int) a False
\a -> (\b -> map (seq b id) (seq b ([]::[] Int))) (seq a (\b -> (undefined::([] Bool))))
map (seq (seq (seq 0 (undefined::Bool)) (\a -> \b -> (undefined::Bool)) (undefined::Int)))
map (seq (seq (id (\a -> (undefined::Int)) ([]::[] Int)) (\a -> undefined::Bool)))
\a -> (\b -> (:) (seq b 2) (b (undefined::Int) 0)) (seq a (\b -> (undefined::Int -> [] Int)))
}}}

To discover the differences, just run the terms (whose types are [Int] -> [Int]) on some partially or fully-defined small lists.

It is possible to construct programs which exhibit space leaks only when optimisation is turned on using some of these terms (examples attached).

All programs have been tested with a pre-built GHC 7.1.20110606 on linux x86-64.

Is this a bug? Well, full laziness comes with a disclaimer that some expressions will get too lazy, but this happens even when we turn off full laziness, so it might be a legitimate bug.",michal.palka
4,3632,22,erik.flister@…,"lift restrictions on records with existential fields, especially in the presence of class constraints",Compiler,6.10.4,7.6.2,,new,low,2012-09-12T04:12:18-0700,"the attached file demos the use of a record with an existential field with a class constraint.  it shows several cases where lifting the current restrictions on accessing and updating this field would be both well-defined and useful.

here is the record definition; the dur field is existential, but constrained to be in class NoteDur.

{{{
data Note = forall x . NoteDur x => Note {
      midiNum :: Int -- 0-255
    , vel     :: Int -- 0-255
    , chan    :: Int -- 0-15
    , measure :: Integral a => a
    , beat    :: Int
    , subdiv  :: RealFrac a => a -- % of beat
    , dur     :: x
    }
}}}

here is a walk through of places in the code where the current restrictions are unnecessary and intrusive:

 1. lines 64-95 -- these functions wouldn't be necessary if record update syntax were enabled for both existential and non-existential fields.  i know 6.12 introduces it for non-existentials, but i don't see why it isn't also possible for existential fields (even without a class constraint).  lines 33-35 and 60 show how much nicer it is to use regular updater syntax in this case.

 2. Line 142.  The same is true for existential accessors when there is a class constraint -- there's no need to restrict this situation because the accessor can have type:
{{{
fieldName :: (SomeClass x) => Record -> x
}}}
   line 142 shows a case where this would be very nice to have.

 3. line 100 + 107 -- the foralls could be implicit (maybe offer an extention that would allow them to be implicit)

 4. lines 134-136 compared to 138-139 show how additional factoring could be achieved if one were allowed to pattern match on the type of an existential with class constraints.

 5. lines 124-127 show how it would be nice to have existential classes

 6. lastly, allow curried updater functions: `(rec {field = }) 5` instead of `(\x -> (rec {field = x})) 5`",eflister
4,5059,22,johan.tibell@…,Pragma to SPECIALISE on value arguments,Compiler,7.0.3,7.6.2,,new,low,2012-09-12T04:13:26-0700,"I've sometimes found myself wishing for this pragma to get some ""partial evaluation on the cheap"". The idea is to allow something like:

{{{
defaultOpts :: Options
defaultOpts = ...

{-# SPECIALISE f defaultOpts :: Int -> Int #-}
f :: Options -> Int -> Int
f opts x = ... f opts ...
}}}

This would desugar into this additional code:

{{{
{-# RULES ""f/spec"" f defaultOpts = f_spec_1 #-}
f_spec_1 = (\opts x -> ... ... f opts ...) defaultOpts -- NB: body of f duplicated
}}}

The hope is that the simplifier and RULE matcher will tidy this up so we get a nice loop back to f_spec_1 with the body of the function specialised for the particular opts.

This is useful when functions are called often with particular arguments. An example would be where ""f"" is an edit-distance function which takes costs to be assigned to each edit, strings to be compared and returns an integer distance. In my library, the costs are given almost always going to be the default ones so I want to make that case fast, but I want to allow the user to supply their own set.

This pragma is somewhat subsumed by:

  1. SpecConstr, if the options are algebraic data/literals that are also scrutinised by the body of f

  2. Static argument transformation, except that the RULE based strategy achieves more code sharing compared to SAT

I think that pragma might be a relatively simple to implement nice-to-have feature.",batterseapower
4,5288,22,malcolm.wallace@…,Less noisy version of -fwarn-name-shadowing,Compiler,7.0.3,7.6.2,,new,low,2012-09-12T04:13:31-0700,"I would like a flag that warns about name-shadowing in more restricted circumstances than the current flag. I.e. I would like examples like these not to produce a warning:

{{{
foo x = ..
  where
    bar x = ...
}}}

{{{
baz z = do
  z <- .... z ...
  return z
}}}

But I would like these to produce one:

{{{
foo x = ..
  where
    x = ... x ...
}}}

{{{
baz z = mdo
  z <- .... z ...
  return z
}}}

Basically warn when a definition shadows *itself*. My motivation is that code like my first two examples is almost never an error in my experience, but my last two examples almost always are examples of my accidentally building a loop that evaluates to _|_.",batterseapower
4,5308,22,johan.tibell@…,Generalize -msse2 command line flag to -msse<version number>,Compiler,7.0.4,7.6.2,,new,low,2012-09-12T04:13:32-0700,"I'm looking into adding support for the `popcnt` instruction. The instruction should be used if the user specifies `-msse4.2`*. I think we should generalize the `-msse2` flag to be just `-msse` followed by a version number.

* Although not formally part of the SSE 4.2 instruction set, the `popcnt` instruction was added at the same time. GCC enables the `popcnt` instruction if you specify `-msse4.2`, so I thought it'd be reasonable for us to do so as well.
",tibbe
5,2940,22,felix.lequen@…,Do CSE after CorePrep,Compiler,6.10.1,7.6.2,simonpj,new,lowest,2012-09-12T04:14:05-0700,"Common sub-expression analysis is deliberately conservative, but it's really ''too'' conservative: we are missing obvious opportunities.  Consider
{{{
{-# OPTIONS_GHC -XBangPatterns -XMagicHash #-}

module Foo where

import GHC.Base

-- CorePrep evaluates (reverse xs) twice
f xs = let !v1 = reverse (reverse xs)
       	   !v2 = filter id (reverse xs)
       in (v1, v2)

-- Even CSE inside CorePrep would not get this right;
-- the strict evaluation of (reverse xs) doesn't scope
-- over the non-strict version
g xs = reverse (reverse xs) ++ filter id (reverse xs)


-- Duplicate evaluation of (x +# 1#)
h :: Int# -> ( Int, Int )
h x = ( I# (x +# 1#), I# ((x +# 1#) *# 2#) )
}}}
If you compile this you'll see that there are obvious missed CSE opportunities in `f`, `g` and `h`; but they only show up after `CorePrep`.  

I guess the right thing is to CSE after `CorePrep`, but then CSE would have to maintain the `CorePrep` invariants, which isn't trivial.  Something to think about.

Simon",simonpj
5,3138,22,lennart@…,Returning a known constructor: GHC generates terrible code for cmonad,Compiler,6.10.1,7.6.2,,new,lowest,2012-09-12T04:14:09-0700,"Lennart reports that GHC generates very poor code for his cmonad package. 
If you want to look at a simple example, look at the Inf.hs example
included in package `cmonad-0.1.1`.
It's very simple, and ghc generates fantastically bad code for it.

It would be great if you could nail down why it's so amazingly unoptimal.
Even with everything inlined and no overloading left, ghc seems to
ignore the INLINE directives and use dictionaries left and right.
When I looked at it a year ago or so, it was a return of one
constructor in a sum.  That is, a function always returns the same constructor, so the case
analysis of the return value is not needed; it should be returned as
an unboxed tuple instead

Another unrelated problem, I think, is that ghc needs to promote
in-memory variables to registers when possible.
Perhaps the new code generator has such a transformation?
",simonpj
5,2836,22,lennart@…,Data.Typeable does not use qualified names,Compiler,6.10.1,7.6.2,,new,lowest,2012-09-12T04:14:05-0700,"The !TyCon in Data.Typeable does not provide the qualified type name.
This can be very annoying if you try to use a !TypeRep as a stored representation of a type (within a run it's OK with the equality on !TypeRep).

I suggest that the !TyCon be enhanced to contain a qualified name, but that the current API be maintained, except for adding some new functions to access qualified name.

If prodded I could provide the Data.Typeable implementation and the fix to ghc.
",guest
5,926,22,mark@…,infinite loop in ShutdownIOManager(),Runtime System,6.5,_|_,,new,lowest,2009-07-07T01:23:26-0700,"Hi,

I have found a way to 'hang' a DLL created using ghc-6.5.20061006 under Win32. This occurs when I dynamically load DLL built using GHC, call one of its exported functions that uses file IO and then exit my program without explicitly releasing the DLL first. I have uploaded a test application to http://eeter.fi.tartu.ee/~mark/ghc_hang.zip that demonstrates this issue.

I am not sure if I can call this a bug, as when I unload the DLL, everything works fine. But this does not happen in GHC-6.4.2 or older versions.

Regards,
Mark",guest
3,7296,21,sternkinder@…,ghc-7 assumes incoherent instances without requiring language `IncoherentInstances`,Compiler (Type checker),7.6.1,7.8.1,simonpj,new,normal,2013-04-12T07:58:10-0700,"the attached examples works with ghc-7 and returns

{{{
    *Main> a
    [Spec1 Spec2]
    *Main> b
    []
}}}

(One may wish that b also returned [Spec1 Spec2])

ghc-6 complains with

{{{
Splittable.hs:16:36:
    Overlapping instances for Test a Spec2
      arising from a use of `test' at Splittable.hs:16:36-43
    Matching instances:
      instance [overlap ok] Test a Spec2
        -- Defined at Splittable.hs:20:13-24
      instance [overlap ok] Test Bool Spec2
        -- Defined at Splittable.hs:25:13-27
    (The choice depends on the instantiation of `a'
     To pick the first instance above, use -XIncoherentInstances
     when compiling the other instance declarations)
    In the second argument of `($)', namely `test a b'
    In the expression: map Spec1 $ test a b
    In the definition of `test':
        test a (Spec1 b) = map Spec1 $ test a b
Failed, modules loaded: none.
}}}

After adding `IncoherentInstances` the file also goes through ghc-6 with the same results.
",maeder
3,1262,21,MartijnVanSteenbergen,RecursiveDo in Template Haskell,Template Haskell,6.6,_|_,,new,normal,2013-01-28T13:59:54-0800,I really want mdo support in Template Haskell!  Thanks!,philip.weaver@…
4,4329,21,tharris@…,GHC.Conc modifyTVar primitive,Compiler,6.12.3,7.6.2,,new,low,2012-09-12T04:12:30-0700,"I would like modifyTVar as a 'write-only' primitive supported by GHC's STM.

The semantic definition is:

> modifyTVar :: TVar a -> (a -> a) -> STM ()
> modifyTVar v f = readTVar v >>= writeTVar v . f

However, explicitly reading then writing the TVar introduces unnecessary interference between transactions. The value held by the TVar does not affect the behavior of the transaction. modifyTVar should not interfere with other transactions that only writeTVar or modifyTVar.

Even if a non-interfering implementation isn't feasible due to the underlying implementation of GHC's STM, providing the function would provide a point for a transparent upgrade in the future. ",dmbarbour
5,2514,21,david.waern@…,Add/Expose Binary API that allows dumping of any GHC Binary instance,GHC API,6.9,7.6.2,nominolo,new,lowest,2012-09-12T04:14:00-0700,"Serialising Names requires that a symbol table is being provided in
the BinHandle so that a string can be mapped to an index in the symbol
table.  API clients like Haddock need this so they can use all Binary
instances of GHC data types.

Whether a symbol table is provided or not is best reflected in the
type (using phantom types / type labels).  For example:
{{{
    data Put symtab a = ...
    data Symtab

    instance Monad (Put b) where ...

    instance Put a Foo where ...

    instance Put Symtab Name where ...

    runPut :: ... -> Put () a -> IO a 
    putWithSymtable :: ... -> Put Symtab a -> IO a
}}}
Similarly for a Get monad

(feature suggested by David Waern)",nominolo
3,7930,20,tim.harris@…,Nested STM Invariants are lost,Runtime System,7.6.3,,fryguybob,new,normal,2013-05-27T10:30:10-0700,"Invariants from a successful nested transaction should be merged with the parent.

{{{
import Control.Concurrent
import Control.Concurrent.STM

main = do
    x <- atomically $
        do a <- newTVar True
           (always (readTVar a) >> retry) `orElse` return ()
           return a
    atomically (writeTVar x False) -- Should not and does not fail

    y <- atomically $
        do a <- newTVar True
           always (readTVar a) `orElse` return ()
           return a
    atomically (writeTVar y False) -- Should fail, but does not!

    putStrLn ""Ahhh!""

    z <- atomically $
        do a <- newTVar True
           always (readTVar a)
           return a
    atomically (writeTVar z False) -- should and does fail
}}}

I know how to fix this.  I'll have a patch with some tests and a fix soon.",fryguybob
3,5412,20,ndmitchell@…,dataTypeConstrs gives unhelpful error message,libraries/base,7.1,7.6.2,,new,normal,2012-09-12T04:12:03-0700,"Take the following program:

{{{
import Data.Data
foo = dataTypeConstrs (dataTypeOf (0 :: Int))
-- raises: *** Exception: Data.Data.dataTypeConstrs
}}}

The implementation of {{{dataTypeConstrs}}} has the type available as a string at this point, so could easily say:

{{{
Exception: Data.Data.dataTypeConstrs is not supported for Int, 
           as it is not an algebraic data type
}}}",NeilMitchell
3,5996,20,conrad@…,fix for CSE,Compiler,7.5,7.8.1,simonpj,patch,normal,2013-06-07T13:06:11-0700,"The current version of CSE is slightly broken -- contrary to the comments
explaining it, it does not add an additional mapping when it substitutes the RHS
of some binding. Taking the example from ```CSE.lhs```

{{{
module Test2 where

data C a b = C a b
a = undefined
{-# NOINLINE a #-}
b = undefined
{-# NOINLINE b #-}

x1 = C a b
x2 = C x1 b
y1 = C a b
y2 = C y1 b
}}}

We want to detect that ```y1``` is the same as ```x1``` and so rewrite it to
```y1 = x1```. But at this point we also want to add a new substitution that
changes ```y1``` to ```x1```. So that we can get ```y2 = C x1 b``` and then
```y2 = x2```. This is '''not''' done by the current code:
{{{
> ghc -O2 -fforce-recomp Test2.hs -ddump-simpl -dsuppress-all -rtsopts
[1 of 1] Compiling Test2            ( Test2.hs, Test2.o )

==================== Tidy Core ====================
Result size = 40

b = undefined
a = b
x1 = \\ @ a_aaf @ b_aag -> C (a) (b)
x2 = \\ @ b_aao @ a_aap @ b1_aaq -> C (x1) (b)
y1 = x1
y2 = \\ @ b_aaG @ a_aaH @ b1_aaI -> C (x1) (b)
}}}

I wrote a patch to fix that and we get the desired result:
{{{

> ~/dev/ghc-work/inplace/bin/ghc-stage2 -O2 -fforce-recomp Test2.hs -ddump-simpl -dsuppress-all -rtsopts
[1 of 1] Compiling Test2            ( Test2.hs, Test2.o )

==================== Tidy Core ====================
  Result size = 30

b = undefined
a = b
x1 = \\ @ a_aal @ b_aam -> C (b) (b)
x2 = \\ @ b_aau @ a_aav @ b1_aaw -> C (x1) (b)
y1 = x1
y2 = x2
}}}

The fix seems quite easy but it made nofib unhappy -- see nofib1
attachment. Apparently there is quite a bit additional alloctation happening in
a few benchmarks. I managed to narrow it down to the ```GHC.IO.Encoding.*```
modules. Adding a simple ```GHC_OPTIONS -fno-cse``` seems to improve the
performance quite a bit (and above the current HEAD!) -- see nofib2 attachment.
There seems to be a bit more code bloat, but the performance looks worth it. I
haven't yet looked into exactly what causes the excessive allocation with CSE in
the ```GHC.IO.Encoding.*``` modules (and I'm also a bit surprised by that -- I
thought the main issue with CSE would be bigger memory usage). So any
suggestions are more than welcome. ;)

All the patches are in https://github.com/michalt/ghc (branch ""cse"") and
https://github.com/michalt/packages-base (branch ""cse"").
",michalt
3,7414,20,conrad@…,plugins always trigger recompilation,Compiler,7.6.1,7.8.1,,new,normal,2013-04-12T11:53:34-0700,"When compiling code with a ghc plugin, e.g. '''ghc -O -fplugin SomePlugin Main.hs''', recompilation is triggered for every module.  This can make plugins difficult to use in environments with many modules shared between executables.

Since a plugin is a GHC library, I would like to propose that plugin arguments and interface hashes be included in the dependencies for compiled modules, in a similar way to how compiler flags are already included.  This would enable ghc to avoid recompilation of modules when using plugins, provided that the plugin and plugin options haven't changed.",jwlato
3,2786,20,patrick@…,Blackhole loops are not detected and reported in GHCi,GHCi,6.8.3,_|_,,new,normal,2012-10-22T04:47:49-0700,"While looking into #2783 I noticed this.  It has never worked, and I was vaguely aware of it, but it seems we don't have a ticket.

{{{
let x = x in x
}}}

in GHCi should report `<<loop>>`.  One issue is that the `interruptTargetThread` global var points to the `ThreadId` running the expression, which will keep it alive and prevent it from being detected as deadlocked.  But that's not all: I think the expression itself is being retained by the main thread (perhaps because it is bound to `it`), which will cause the child thread to also stay alive.
",simonmar
3,3827,20,mle+hs@…,Compiling fails on linux-powerpc,Compiler,6.12.1,_|_,,new,normal,2011-04-10T16:31:26-0700,"I get the following error after doing ./configure && make
{{{
ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 6.12.1 for powerpc-unknown-linux):
        Error in array index
}}}
The command where the failure happens is:
{{{
""inplace/bin/ghc-stage1""   -H32m -O    -package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.    -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -split-objs -package-name ghc-prim -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -XGenerics -fno-warn-deprecated-flags     -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf  o -hcsuf hc -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o
}}}
",speleologic
3,2101,20,ryani.spam@…,Allow some form of type-level lemma,Compiler,6.8.2,_|_,,new,normal,2008-09-30T08:51:41-0700,See http://www.haskell.org/pipermail/haskell/2008-February/020230.html,guest
3,5793,20,ndmitchell@…,make nofib awesome,NoFib benchmark suite,,_|_,dterei,new,normal,2013-02-09T03:27:10-0800,"Nofib is the standard tool GHC developers use to benchmark changes to the compiler. Its overall design is OK but it's had no love and care for many years and has bittrotted such that it isn't useful in a lot of situations.

This task is about making nofib useful again.

The breakdown for this is something like:

1. Think and maybe fix nofib framework design. It has 'ways' which I think correspond to compilation method but more in the sense of 'dynamic' vs 'static', seems it may not suite being able to use ways for 'fasm' vs 'fllvm'. There is also the concept of 'modes' which corresponds to different benchmark input. So 'normal' and 'slow' for getting different run-times. At moment no easy way to select which benchmark groups to run, so may want to change that. I guess we should just decide, what knobs do we want to be able to easily tweak, and see how well the current design allows that.

'''Note''' there is a shake build system attached that does a lot of this (done by Neil Mitchell!). An explanation of it can be found here: http://neilmitchell.blogspot.com/2013/02/a-nofib-build-system-using-shake.html

The design discussion of it is mostly lost as it was done on private email sorry.

2. Fixup the runtimes for benchmarks to be significant. This might be best done by changing the way we run benchmarks and collect results to make sure they are meaningful.

E.g., Lots of great discussion and links to papers on this thread

http://www.haskell.org/pipermail/ghc-devs/2013-February/000307.html

3. Above task is to fix normal but we may want to fixup slow as well and perhaps add a 'fast' mode where benchmarks run in around 1 second.

4. Maybe add more benchmarks to the suite (text, bytestring, performance regressions from ghc testsuite, vector....)",dterei
4,4162,20,chowells79@…,GHC API messes up signal handlers,GHC API,6.12.3,7.6.2,,new,low,2012-09-12T04:12:25-0700,"A side-effect of using the {{{runGhc}}} function is that some signal handlers are modified and not restored afterwards (see function {{{initGhcMonad}}}). In particular, the handler for {{{SIGINT}}} installed by ghc throws an exception to a thread stored in a global variable, which initially corresponds to the thread from which {{{runGhc}}} was run.

This is a particularly problematic for programs that wish to run ghc ""in the background"" on its own thread. For example, consider this code:

{{{
import qualified GHC
import qualified MonadUtils as GHC
import qualified GHC.Paths as GHC

import Control.Concurrent ( forkIO, threadDelay )

main = do
   putStrLn ""waiting for 5 seconds...""
   threadDelay $ 5 * 1000 * 1000
   putStrLn ""starting...""
   forkIO $ GHC.runGhc (Just GHC.libdir) (GHC.liftIO $ putStrLn ""hello"")
   putStrLn ""waiting for 10 seconds""
   threadDelay $ 10 * 1000 * 1000
   putStrLn ""exiting after final wait""
}}}

One can interrupt this program with Ctrl-C during the first five seconds of execution only.

It is not clear to me how one can safely workaround this problem. For instance, one could manually restore the program's original handlers at the beginning of execution, that is, transform:

{{{
runGhc action
}}}

into something like this:

{{{
runGhc $ (liftIO restoreProgramHandlers >> action)
}}}

but I don't know if this is safe (i.e., what happens if ghc is run without its own handlers installed).
",jcpetruzza
4,4308,20,pumpkingod@…,LLVM compiles Updates.cmm badly,Compiler (LLVM),6.13,7.6.2,,new,low,2012-09-12T04:12:30-0700,"Simon M. reported that compiled rts/Updates.cmm on x86-64 with the LLVM backend produced some pretty bad code. The ncg produces this:

{{{
stg_upd_frame_info:
.Lco:
       movq 8(%rbp),%rax
       addq $16,%rbp
       movq %rbx,8(%rax)
       movq $stg_BLACKHOLE_info,0(%rax)
       movq %rax,%rcx
       andq $-1048576,%rcx
       movq %rax,%rdx
       andq $1044480,%rdx
       shrq $6,%rdx
       orq %rcx,%rdx
       cmpw $0,52(%rdx)
       jne .Lcf
       jmp *0(%rbp)
.Lcf:
       [...]
}}}

The LLVM backend produces this though:

{{{
stg_upd_frame_info:                     # @stg_upd_frame_info
# BB#0:                                 # %co
       subq    $104, %rsp
       movq    8(%rbp), %rax
       movq    %rax, 24(%rsp)          # 8-byte Spill
       movq    %rbx, 8(%rax)
       mfence
       movq    $stg_BLACKHOLE_info, (%rax)
       movq    %rax, %rcx
       andq    $-1048576, %rcx         # imm = 0xFFFFFFFFFFF00000
       andq    $1044480, %rax          # imm = 0xFF000
       shrq    $6, %rax
       addq    %rcx, %rax
       addq    $16, %rbp
       cmpw    $0, 52(%rax)
       movsd   %xmm6, 88(%rsp)         # 8-byte Spill
       movsd   %xmm5, 80(%rsp)         # 8-byte Spill
       movss   %xmm4, 76(%rsp)         # 4-byte Spill
       movss   %xmm3, 72(%rsp)         # 4-byte Spill
       movss   %xmm2, 68(%rsp)         # 4-byte Spill
       movss   %xmm1, 64(%rsp)         # 4-byte Spill
       movq    %r9, 56(%rsp)           # 8-byte Spill
       movq    %r8, 48(%rsp)           # 8-byte Spill
       movq    %rdi, 40(%rsp)          # 8-byte Spill
       movq    %rsi, 32(%rsp)          # 8-byte Spill
       je      .LBB1_4
}}}

This has two main problems:

  1. mfence instruction (write barrier) isn't required. (write-write barriers aren't required on x86)
  2. LLVM backend is spilling a lot of stuff unnecessarily.

Both these I think are fairly easy fixes. LLVM is handling write barriers quite naively at the moment so 1. is easy. The spilling problem I think is related to a previous fix I made where I need to explicitly kill some of the stg registers if they aren't live across the call, otherwise LLVM rightly thinks they are live since I always pass the stg registers around (so live on entry and exit of every function unless I kill them).",dterei
4,4800,20,gideon@…,Memory Leak when Compiling qtHaskell,Compiler,6.12.3,7.6.2,,new,low,2012-09-12T04:12:33-0700,"I get an out-of-memory error about two thirds of the way through building qtHaskell (latest version, 1.1.4). If I start again, the remaining modules are compiled successfully, although GHC's memory usage creeps up to about 1.5Gb by the time it's finished.

This is on Win7 x64 with 4Gb RAM.",gidyn
4,4861,20,ndmitchell@…,Documentation for base does not include special items,libraries/base,7.0.1,7.6.2,,new,low,2012-09-12T04:13:23-0700,"The documentation for base does not include tuples, lists or arrow. I realise these are special in Haskell, but it seems a shame they aren't documented.

For tuples, the documentation for base doesn't include them in either Prelude or Data.Tuple, but the documentation for ghc-prim includes them in GHC.Unit and GHC.Tuple. I think the lack of documentation for tuple types is a bug, since it would be relatively easy for them to be documented, and does make the documentation more complete.

For lists ([], (:)), there is no documentation in either base or ghc-prim. It would be nice if they were documented in Prelude and Data.List, but not if it was too much effort (I can imagine that Haddock can't accept list definitions).

For the arrow type ->, it's unclear if it can reasonably be documented, so it might be worth thinking about but probably not bothering to document.

The reason I'm interested in ensuring complete documentation is that Hoogle currently doesn't know about tuple constructors in the base library, but it does know about them in ghc-prim, which seems wrong.",NeilMitchell
4,5224,20,chak@…,Improve consistency checking for family instances,Compiler,7.0.3,7.6.2,simonpj,new,low,2012-09-12T04:13:30-0700,"Several compiler-performance tests got worse when I added the new generic default methods (with Pedro):
 * `T3064`: peak_megabytes_allocated 24 is more than maximum allowed 16
 * `IndTypesPerf`: needs more than the 20M heap it is given
 * `T4801`: max_bytes_used 31.4M is more than maximum allowed 30M

For the first two of these we know exactly why: the (necessarily) eager overlap check is reading interface files that are otherwise not read, becuase of the new `Rep` type family instances in `Data.Maybe` and so on.  Both these tests use type families.

For T4801 it's more mysterious.  The test does not use type families, and no new interface files are read, but residency increases.  So the cause may be different.

I'm pretty sure we can improve matters by propagating a bit more info; specifically, rather than a module simply saying ""I have some type familily instances"" it can say ""I have type family instances for F, G, H"".

I have marked the three tests as expect-broken for now, with the ticket to remind me to get back to it.
",simonpj
4,5248,20,gideon@…,Infer type context in a type signature,Compiler (Type checker),7.0.3,7.6.2,,new,low,2012-09-12T04:13:30-0700,"If I have code such as

{{{
class Foo f where
    foo :: a -> f a

data Bar f a = Foo f => Bar {bar :: f a}

instance Foo (Bar f) where
    foo a = Bar (foo a)
}}}

GHC will demand `Foo f =>` on the instance declaration, even though this can be inferred from the definition of Bar.

I understand ''why'' this is happening, but it should not be necessary to repeat information already given. Some code violates DRY dozens of times because of this limitation.",gidyn
5,3034,20,twhitehead@…,divInt# floated into a position which leads to low arity,Compiler,6.10.1,7.6.2,,new,lowest,2012-09-12T04:14:07-0700,"Tyson Whitehead saw this in the Core output of one of his programs compiled using the MTL StateT:

{{{
$wdigit_s1GR [ALWAYS LoopBreaker Nothing] :: GHC.Prim.Int#
                                           -> GHC.Types.Int
                                           -> Control.Monad.State.Strict.StateT
                                                GHC.Types.Int
                                                (Control.Monad.Error.ErrorT
                                                   GHC.Base.String
                                                   Control.Monad.Identity.Identity)
                                                (GHC.Types.Int, GHC.Types.Int)
[Arity 1
Str: DmdType L]
$wdigit_s1GR =
\ (ww_X1H6 :: GHC.Prim.Int#) ->
  let {
    lvl_s1H5 [ALWAYS Just D(T)] :: GHC.Types.Int
    [Str: DmdType]
    lvl_s1H5 =
      case GHC.Prim.-# 2147483647 ww_X1H6 of wild2_a1xs [ALWAYS Just L] {
        __DEFAULT ->
          case GHC.Base.divInt# wild2_a1xs 10
          of wild21_a1xt [ALWAYS Just L] { __DEFAULT ->
          GHC.Types.I# wild21_a1xt
          };
        (-2147483648) -> lvl_s1Ha
      } } in
  (\ (eta_X1nK :: GHC.Types.Int) (eta_s1Dl :: GHC.Types.Int) ->
     case eta_s1Dl
     of y_XrP [ALWAYS Just A] { GHC.Types.I# ipv_s19d [ALWAYS Just L] ->
     case GHC.Prim.<=# ipv_s19d 214748363
     of wild_a19h [ALWAYS Dead Just A] {
       GHC.Bool.False ->
         case lvl_s1H5
         of wild1_X1zB [ALWAYS Just A]
         { GHC.Types.I# y_X1zG [ALWAYS Just L] ->
         case GHC.Prim.<=# ipv_s19d y_X1zG
         of wild_X1z [ALWAYS Dead Just A] {
           GHC.Bool.False ->
             a_s1Hk
             `cast` (right
}}}

This REALLY SHOULD have arity 3 because that allows:
 * More worker/wrapper
 * Less sharing of trivial partial applications elsewhere in his program

Here is my reply to him, explaining why it all happens:

{{{
Yes - GHC wants to share the work of (maxBound-x)`div`10 between
several partial applications of ""digit"". This is usually a good idea,
but in this case it sucks because it's resulted in a massively
increased arity. IMHO GHC should fix this by:
* Marking divInt# INLINE in the base library. This would result in
your code would just containing uses of quotInt#
* Making some operations cheap even if they may fail
(PrimOp.primpOpIsCheap should change). Though this might mean that we
turn non-terminating programs into terminating ones (such operations
get pushed inside lambdas) but this is consistent with our treatment
of lambdas generally.

Actually, your divInt# call wouldn't even usually be floated out to
between two lambdas, but at the time FloatOut runs there is something
in between the \x lambda and the lambdas from the state monad - the
monadic bind operator! So FloatOut feels free to move the computation
for ""x"" up even though that >>= will go away as soon as we run the
simplifier. What a disaster!
}}}

So one of FloatOut and primOpIsCheap probably needs to be fixed.

I've attached a program that can reproduce this issue.",batterseapower
5,3960,20,"jwlato@…, rl",ghc panic when attempting to compile DPH code,Data Parallel Haskell,6.12.1,7.6.2,rl,new,lowest,2012-09-12T04:14:15-0700,"the function ""tmpfn"" in the attached code causes ghc to panic (the 'impossible' happened).  This bug is present in ghc 6.12.1 and 6.13.20100226
{{{
ghc: panic! (the 'impossible' happened)
  (GHC version 6.12.1 for i386-apple-darwin):
	VectMonad.lookupFamInst: not found: 
    dph-seq:Data.Array.Parallel.Lifted.PArray.PData{tc rq5}
      (dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
         ghc-prim:GHC.Types.Double{(w) tc 3u},
       dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
         ghc-prim:GHC.Types.Double{(w) tc 3u},
       dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
         (dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
            (ghc-prim:GHC.Types.Int{(w) tc 3J},
             ghc-prim:GHC.Types.Double{(w) tc 3u})),
       dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
         ghc-prim:GHC.Types.Double{(w) tc 3u},
       dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
         (dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
            (ghc-prim:GHC.Types.Int{(w) tc 3J},
             ghc-prim:GHC.Types.Double{(w) tc 3u})),
       dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
         ghc-prim:GHC.Types.Double{(w) tc 3u})
}}}",jwlato
2,7678,19,anton.nik@…,GHC should compile cleanly with clang,Compiler,7.7,7.8.1,thoughtpolice,new,high,2013-04-14T00:14:02-0700,"I'm running into several difficulties (which I'll catalog shortly) building GHC HEAD with Clang 3.2. These mostly seem to be difficulties relating to the preprocessor and the fact clang does not really respect ```-traditional-cpp``` mode, and that it is stricter than gcc about whitespace and whatnot too. This means code like:

{{{

{-# RULES

 ""thing"" ...

  #-}

}}}

becomes invalid: ```clang``` is strict about the fact that preprocessor definitions must occur on the beginning of a line. There seems to be a bug in the preprocessor directive source code to this effect (that it doesn't handle whitespace before a directive.) It's quite unfortunate, because we do this a lot.

This also causes build failures in the parser due to some crazy CPP hackery we do. I'll follow up with that shortly.

As a workaround, we may have to force ```CPP``` to just continue being ```cpp``` which will Do The Right Thing, while ```CC``` will use ```clang``` instead. Or we'll have to have some script that seds whitespace out or something.

This currently blocks #7602 since I can't test my fix otherwise.",thoughtpolice
2,7919,19,mail@…,Heap corruption (segfault) from large 'let' expression,Runtime System,7.6.3,7.8.1,simonmar,merge,high,2013-05-24T07:04:23-0700,"The attached test program reliably triggers an assertion in the storage manager with the `-debug` rts.

{{{
LargeUse: internal error: ASSERTION FAILED: file rts/sm/GCUtils.c, line 208

    (GHC version 7.6.3 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}

This behaviour is reproducible with many recent ghc versions (tried 7.6.3, 7.4.2, 6.12.3) and all fail at the same assertion when using the `-debug` rts. (Without `-debug` we get a more random variety of segfaults and GC errors.)

It looks like a pretty clear case of heap corruption. I'll explain why...

The test program uses TH to generate a program that looks like this:
{{{
data Large = Large Int Int ... -- 512 non-strict Int fields

test =
  let step (Large i1 i2 ... i512) =
        let j1 = i1 + i4
            j2 = i2 + i7
            ...
            j511 = i511 + i510
            j512 = i512 + i1
         in Large j1 j2 ... j512

   in runSteps step 100000 (Large 1 1 ... 1)

-- basically an unfoldr:
runSteps :: (state -> (state, Int)) -> Int -> state -> [Int]
runSteps f n i | n <= 0    = []
               | otherwise = case f i of
                               (i', r) -> r : runSteps f (n - 1) i'
}}}

We use TH to generate this program, and we use a ""size"" parameter that determines size of the data constructor (and corresponding letrec). This makes it easy to find the size threshold where it fails.

For small sizes this program works fine, and for larger values it triggers the assert. With ghc 7.6.3 on a x86-64 machine, the magic threshold is 511: that is, the program works fine with size 510 and hits the assertion at size 511. This is suspiciously close to 512. And of course on a 64bit machine 512 * 8 is 4k, which is the storage manager's block size. And the failing assertion is in a bit of the storage manager that is dealing with blocks...

{{{
        // If this block does not have enough space to allocate the
        // current object, but it also doesn't have any work to push, then 
        // push it on to the scanned list.  It cannot be empty, because
        // then there would be enough room to copy the current object.
        if (bd->u.scan == bd->free)
        {
            ASSERT(bd->free != bd->start);
            push_scanned_block(bd, ws);
        }
}}}

So it looks very much like we have a situation where something is writing over the end of a block and messing up the SM's data structures.

But, it is not nearly as simple as the data constructor being too big. We can demonstrate other programs that use much larger data constructors without any problem at all. Our suspicion falls on the big letrec.

Indeed with this program if we change the data constructor to have strict fields then it no longer fails, and we can run it with much larger data constructor sizes. What would be different between strict and non-strict fields here? Well, one observation is that when it is strict then ghc can (and does) turn the code into a big cascade of case expressions, while when it is non-strict then the STG code is all 'let's.

{{{
        case tpl_s6jQ of tpl_s6Ak {
          __DEFAULT ->
              case tpl_s6jS of tpl_s6Al {
                __DEFAULT ->
                    case tpl_s6jU of tpl_s6Am {
    -- etc for all 500+ elements
}}}
versus
{{{
              let {
                sat_s5UK :: GHC.Types.Int
                [LclId] =
                    \u [] GHC.Num.$fNumInt_$c+ i511_s5Ly i1_s5E9; } in
              let {
                sat_s62X :: GHC.Types.Int
                [LclId] =
                    \u [] GHC.Num.$fNumInt_$c+ i510_s5R2 i509_s5UG; } in
              let {
                sat_s62W :: GHC.Types.Int
                [LclId] =
                    \u [] GHC.Num.$fNumInt_$c+ i509_s5UG i506_s5UC; } in
    -- etc for all 500+ elements
}}}

Note also, that it is nothing to do with the obvious space leak here. If we modify the code to generate an NFData instance and to use deepseq at each iteration then we eliminate the space leak, but we keep the big stg 'let', and it still fails.",duncan
3,5821,19,illissius@…,SPECIALISE fails with a cryptic warning,Compiler,7.5,7.6.2,,new,normal,2012-09-12T04:12:09-0700,"Example:

{{{
type family T a
type instance T Int = Bool

foo :: Num a => a -> T a
foo = undefined

{-# SPECIALISE foo :: Int -> Bool #-}
}}}

GHC produces this warning:

{{{
    RULE left-hand side too complicated to desugar
      case cobox of _ { GHC.Types.Eq# cobox ->
      (foo @ Int $dNum)
      `cast` (<Int> -> cobox :: (Int -> T Int) ~# (Int -> Bool))
      }
}}}

Given that rewrite rules don't reliably work in the presence of type families, I somewhat suspect that GHC won't be able to generate a sensible specialisation here but it should produce a better diagnostic.",rl
3,7670,19,remi.turk@…,StablePtrs should be organized by generation for efficient minor collections,Runtime System,7.7,7.8.1,,new,normal,2013-04-13T04:20:26-0700,"Currently, stable pointers are all in one giant pointer table (see markStablePtrTable); this results in pretty bad GC behavior when you create a lot of stable pointers (Peaker has a test-case which he thinks is suffering due to repeated traversal of the stable pointers list.) We should partition them up into generations like we do for mutable lists. There might be some trickiness keeping the table up-to-date after GCs.",ezyang
3,6024,19,ross@…,"Allow defining kinds alone, without a datatype",Compiler (Type checker),7.5,7.8.1,,new,normal,2013-01-25T07:52:58-0800,"Sometimes we want to define a kind alone, and we are not interested in the datatype. In principle having an extra datatype around is not a big problem, but the constructor names will be taken, so they cannot be used somewhere else. A contrived example:
{{{
data Code = Unit | Prod Code Code

data family Interprt (c :: Code) :: *
data instance Interprt Unit       = Unit1
data instance Interprt (Prod a b) = Prod1 (Interprt a) (Interprt b)
}}}
We're only interested in the constructors of the data family `Interprt`, but we cannot use the names `Unit` and `Prod` because they are constructors of `Code`.

The suggestion is to allow defining:
{{{
data kind Code = Unit | Prod Code Code
}}}
Such that `Code` is a kind, and not a type, and `Unit` and `Prod` are types, and not constructors.

Note that using ""data kind"" instead of just ""kind"" means the word ""kind"" does not have to be a reserved keyword.

You could also think you would want to have datatypes that should not be promoted:
{{{
data K

data type T = K
}}}
But I don't see a need for this, as the fact that the `K` constructor is promoted to a type does not prevent you from having a datatype named `K`.",dreixel
3,1168,19,adam@…,Optimisation sometimes decreases sharing in IO code,Compiler,6.6,_|_,,new,normal,2013-01-27T13:44:41-0800,"The simplifier is losing sharing in spectral/calendar, probably because we're being a bit fast-and-loose with eta-expanding State# lambdas.  A quick look at the Core shows that `calFor year` is not shared across multiple executions.",simonmar
3,3549,19,jmillikin@…,unlit does not follow H98 spec,Compiler,6.10.4,_|_,,new,normal,2011-09-13T08:51:32-0700,"The Haskell 98 spec has this to say about the [http://haskell.org/onlinereport/syntax-iso.html Latex \begin{code} \end{code}] style:

    An alternative style of literate programming is particularly suitable for use with the LaTeX text processing system. In this convention, only those parts of the literate program that are entirely enclosed between \begin{code}...\end{code} delimiters are treated as program text; all other lines are comment. More precisely:

    * Program code begins on the first line following a line that begins \begin{code}.
    * Program code ends just before a subsequent line that begins \end{code} (ignoring string literals, of course).

The key phrases are ""a line that begins \begin{code}"" and ""line that begins \end{code}"". This means the semantics is something like:

{{{
classifyLine s
  | ""\\begin{code}"" `isPrefixOf` s = BeginCode
  | ""\\end{code}""   `isPrefixOf` s = EndCode
}}}

GHC's `unlit` C program uses:

{{{
    if (strcmp(buf, ""\\begin{code}"") == 0)
        return BEGIN;
}}}

The equivalent semantics in the style above would be:
{{{
classifyLine s
  | ""\\begin{code}"" == s = BeginCode
  | ""\\end{code}""   == s = EndCode
}}}

It seems fairly clear from the spec that GHC's unlit program is wrong in this respect.

The practical consequence is that Cabal's unlit and GHC's one do not match and this [http://haskell.org/pipermail/haskell-cafe/2009-September/066780.html catches people out]. There is [http://www.haskell.org/haskellwiki/Literate_programming#Hiding_code_from_Haskell explicit advice on the Haskell wiki] recommending that people take advantage of this GHC bug.",duncan
3,3872,19,anton.nik@…,New way to make the simplifier diverge,Compiler,6.12.1,_|_,,new,normal,2011-08-10T08:32:06-0700,"GHC's simplifier can go into a loop if you use fixpoints in a funny way, as documented here http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html#bugs-ghc (12.2.1, third bullet). But GADTs provide new opportunities.  This ticket records one, thanks to Ryan Ingram and Matthieu Sozeau:
{{{
{-# LANGUAGE GADTs #-}
module Contr where

newtype I f = I (f ())
data R o a where R :: (a (I a) -> o) -> R o (I a)

run :: R o (I (R o)) -> R o (I (R o)) -> o
run x (R f) = f x
rir :: (R o) (I (R o))
rir = R (\x -> run x x)

absurd :: a
absurd = run rir rir
}}}
Now the simplifier can loop.  Look:
{{{
run rir rir

= {inline run}
  case rir of R f -> f rir

= {case of known constructor}
  let { f = \x -> run x x } in f rir

= {inline f}
  run rir rir
}}}
",simonpj
3,3919,19,vogt.adam@…,Or-patterns as GHC extension,Compiler,,_|_,,new,normal,2010-06-13T03:44:59-0700,"Or-patterns is a way of grouping together patterns that match to the same value. A construct like

{{{
 fun 0 _ = E
 fun _ 0 = E
}}}

Could more concisely be written as, for example

{{{
 fun 0 _
  || _ 0 = E
}}}

As a concrete example why this is beautiful and how it could look, see ''Red-black trees in a functional setting, C. Okasaki'' [1].

I don't know enough about GHC internals to know the obvious way to implement this, but I would gladly give it a try given pointers in the right direction.

[1] http://www.eecs.usma.edu/webs/people/okasaki/jfp99.ps",BjornEdstrom
3,5416,19,sanzhiyan@…,Local modules and Template Haskell declaration splices,Compiler,7.2.1,_|_,,new,normal,2011-08-25T09:48:24-0700,"Sometimes you want a Template Haskell splice to expand to a bunch of declarations, ''some of which are not visible to the context''.  A trivial example might be
{{{
module M where
 $(f 4)

====> expands to 
module M where
 helper = ...blah...
 real_fun = ...helper....
}}}
But `helper` is only a helper function for `real_fun` and should not be exported by M, nor should it conflict with other definitions in M.

See #5398 for a more concrete example, and (at the end) a speculative suggestion for ""local modules"" that might be a good design.

Another thing you might want is for a splice to expand into some import declarations that bring some new stuff into scope.  That too might be possible using this design.

Prioity uncertain, details very uncertain.  I'm just making the ticket to keep track of the idea.",simonpj
4,3753,19,dtrebbien@…,Make ghci's -l option consistent with GNU ld's -l option,GHCi,6.12.1,7.6.2,,new,low,2012-09-12T04:12:20-0700,"Currently, ghci accepts -l options of the format -lxyz. On Linux, this is treated as a request for libxyz.so. The GNU ld -l option is more flexible. It accepts either -lxyz or -l xyz. Also, it accepts -l:filename or -l :filename. When this form is used, the filename is not modified by prepending ""lib"" and appending "".so"". I request that GNU ld's -l forms be accepted by ghci.",hgolden
4,5266,19,dtrebbien@…,Licensing requirements and copyright notices,None,,7.6.2,,new,low,2012-09-12T04:13:30-0700,"I'm not sure where or how to bring this up, but I figured I would inform you that complying with the licensing requirements to distribute executables programmed in Haskell (using GHC) seems to be tiresome.

I have a personal project written in Haskell and Lua, and I recently tried to make sure that I comply with the necessary requirements to distribute it. My result was a 1660-line copyright file (http://www.houeland.com/kol/docs/copyright), which I believe is excessive.

This mostly stems from the use of BSD-style licenses for libraries, which require copyright notices to be reproduced for redistributions in binary form.

Many of them are based on code from the GHC project + the Haskell 98 Report + the Haskell Foreign Function Interface specification. I think it would be nice if at least those parts could clearly be distributed using only one reproduction of the GHC license (including allowing derived binary forms to not include the restrictions against claiming to be definitions of the Haskell 98 Language / Foreign Function Interface). Currently the GHC-based libraries have licenses that say they're derived from GHC and include the GHC license notice. The libraries are listed as BSD3 in cabal files, but it's not clear to me that the statement actually covers licensing for the entirety of the library (developments after the split), and whether all GHC-based libraries can currently be distributed using a single copyright notice.

Generally, many of the other available Haskell libraries also seem to use BSD-style licenses, which can be a hassle to comply with for binary redistributions, mostly when dependencies also use separate BSD-style licenses that must be included. Having a 'default' license in the Haskell community that's similar to Boost or zlib instead of BSD3 might be preferable for the many smaller libraries available. Many of the libraries actually have different licenses (but similar ones such as MIT, or people modifying parts of their license file) while being listed as BSD3 in cabal files.

I don't know exactly what you can do about this, but an easier licensing landscape for binary redistributions would certainly be nice. (And possibly tools for automatically listing licensing restrictions and producing copyright notices accurately.)
",houeland
5,2340,19,marco-oweber@…,Improve Template Haskell error recovery,Template Haskell,6.8.2,7.6.2,,new,lowest,2012-09-12T04:13:57-0700,"Marc Weber wants better error recovery in TH's Q monad: http://www.haskell.org/pipermail/template-haskell/2008-May/000666.html

The Quasi monad is defined thus:
{{{
class (Monad m, Functor m) => Quasi m where
	-- Fresh names
  qNewName :: String -> m Name

	-- Error reporting and recovery
  qReport  :: Bool -> String -> m ()	-- Report an error (True) or warning (False)
					-- ...but carry on; use 'fail' to stop
  qRecover :: m a -> m a -> m a		-- Recover from the monadic 'fail'
					-- The first arg is the error handler
 
	-- Inspect the type-checker's environment
  qReify :: Name -> m Info
  qLocation :: m Loc

	-- Input/output (dangerous)
  qRunIO :: IO a -> m a
}}}
A sensible change (but it would be a change) would be to change `qRecover` thus:
{{{
  qRecover :: m a -> ([(Bool,String)] -> m a) -> m a
  -- (qRecover q f) runs the action `q`, collecting all the messages
  -- emitted by `qReport`.  If the action `q` calls the monad `fail`,
  -- these messages are passed to `f`.  If the action `q` does not call
  -- `fail`, the messages are retained in the monad, just as if the 
  -- `qRecover` was not there.
}}}
Comments?  This would be quite easy to implement in 6.10.  

Simon",simonpj
1,7134,18,bos@…,ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32,GHCi,7.6.1-rc1,7.8.1,igloo,new,highest,2013-03-13T05:44:48-0700,"I downloaded ghc-7.6.0.20120810-x86_64-windows.exe and attempting to run GHCi dumps the following error message:

{{{
C:\Users\Cetin>ghci
GHCi, version 7.6.0.20120810: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... ghc.exe: internal error: R_X86_64_PC32: Hig
h bits are set in 7f9585f95a0 for WaitForSingleObject
    (GHC version 7.6.0.20120810 for x86_64_unknown_mingw32)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

}}}

Tested on Windows 8 Release Preview 64-bit.",cetinsert
1,7926,18,mateusz@…,eventfd: unsupported operation when doing anything,Compiler,7.6.3,7.8.1,AndreasVoellmy,new,highest,2013-06-18T07:50:12-0700,"I'm using Debian jessie; sources.list is thus:

{{{deb http://ftp.us.debian.org/debian jessie main contrib non-free}}}

Ran apt-get upgrade 10 minutes ago. The contents of /var/log/apt/history.log (sorry for the massive list, not sure how to narrow it down): https://gist.github.com/joelteon/07c912a3e7e49be820cc

ghc/ghci output (exit 1):

{{{eventfd: unsupported operation (Function not implemented)}}}

When launching a precompiled executable, the first time it executes an I/O action (exit 1):

{{{hClose: user error (Pattern match failure in do expression at libraries/base/GHC/Event/Thread.hs:84:3-10}}}

`strace ghci` output is in this gist: https://gist.github.com/anonymous/dcc02c8b29a65ec49be6",guest
2,7011,18,pho@…,32bit GHC 7.4.2 cannot compile integer-gmp on OS X 10.8,libraries (other),7.5,7.8.1,,new,high,2012-10-11T11:27:09-0700,"If I use the 32bit version of GHC 7.4.2 (OS X installer from the GHC downloads page) on OS X 10.8 DP4 with Xcode 4.5 DP, the compilation of package integer-gmp (from the Git repo) fails. Specifically, the GMP files seem to be compiled for the wrong architecture and hence the linker complains — log file attached.

This problem may well also present on earlier version of OS X as well. (I haven't used the 32bit version for a while.)",chak
2,7028,18,pho@…,incorrect link paths for in mac os x after install,Build System,7.4.2,7.8.1,igloo,new,high,2012-10-11T14:20:21-0700,"I've built and installed 7.4.2 fron source:
{{{
iceman:ghc-7.4.2 andy$ otool -L /usr/local/lib/ghc-7.4.2/libHSrts-ghc7.4.2.dylib/usr/local/lib/ghc-7.4.2/libHSrts-ghc7.4.2.dylib:
	/usr/local/lib/ghc-7.4.2/libHSrts-ghc7.4.2.dylib (compatibility version 0.0.0, current version 0.0.0)
	/Users/andy/src/ghc-7.4.2/libffi/build/inst/lib/libffi.5.dylib (compatibility version 6.0.0, current version 6.10.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
	/opt/local/lib/gcc47/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
}}}
Lib rts still links again the libffi in my home directory.

It should be linked against:
  /usr/local/lib/ghc-7.4.2/libffi.dylib

This problem also affects the binary distribution.
",andykitchen
2,7143,18,shelarcy@…,ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version,Compiler (LLVM),7.6.1-rc1,7.8.1,dterei,new,high,2013-01-17T20:17:08-0800,"I have downloaded:

ghc: ghc-7.6.0.20120810-x86_64-windows.exe

mingw64: http://www.drangon.org/mingw/mirror.php?num=2&fname=mingw-w64-bin-x86_64-20120807.7z 

llvm64: http://www.drangon.org/mingw/mirror.php?num=2&fname=llvm-3.1-w64-bin-x86_64-20120610.7z

my path contains:

{{{
/c/ghc/ghc-7.6.0.20120810/bin:/c/Users/Cetin/AppData/Roaming/cabal/bin:/c/llvm/bin:/c/mw64/bin
}}}


When I run:

{{{
ghc -fllvm --make Main.hs
}}}

I get:

{{{
[1 of 1] Compiling Main             ( Main.hs, Main.o )

<no location info>:
    Warning: Couldn't figure out LLVM version!
             Make sure you have installed LLVM
}}}

Attached is the output from:

{{{
ghc -v3 -fllvm --make Main.hs
}}}

for all Main.hs - it mentions:

{{{
*** LlVM CodeGen:
Error (figuring out LLVM version): : runInteractiveProcess: invalid argument (Invalid argument)

<no location info>:
    Warning: Couldn't figure out LLVM version!
             Make sure you have installed LLVM
*** LLVM Optimiser:
"""" ""C:\Users\Cetin\AppData\Local\Temp\ghc6036_0\ghc6036_0.ll"" ""-o"" ""C:\Users\Cetin\AppData\Local\Temp\ghc6036_0\ghc6036_0.bc"" ""-mem2reg"" ""--enable-tbaa=true""


Failed: """" ""C:\Users\Cetin\AppData\Local\Temp\ghc6036_0\ghc6036_0.ll"" ""-o"" ""C:\Users\Cetin\AppData\Local\Temp\ghc6036_0\ghc6036_0.bc"" ""-mem2reg"" ""--enable-tb
}}}",cetinsert
2,7490,18,pho@…,ghc-stage1 panic when building a cross-compiler or cross-building a compiler,Compiler,7.7,7.8.1,igloo,new,high,2013-01-31T13:28:38-0800,"{{{
""inplace/bin/ghc-stage1"" -static  -H64m -O0 -fasm    -package-name integer-simple-0.1.1.0 -hide-all-packages -i -ilibraries/integer-simple/. -ilibraries/integer-simple/dist-install/build -ilibraries/integer-simple/dist-install/build/autogen -Ilibraries/integer-simple/dist-install/build -Ilibraries/integer-simple/dist-install/build/autogen -Ilibraries/integer-simple/.    -optP-include -optPlibraries/integer-simple/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0  -package-name integer-simple -Wall -XHaskell98 -XCPP -XMagicHash -XBangPatterns -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XNoImplicitPrelude -O -fasm  -no-user-package-db -rtsopts      -odir libraries/integer-simple/dist-install/build -hidir libraries/integer-simple/dist-install/build -stubdir libraries/integer-simple/dist-install/build -hisuf hi -osuf  o -hcsuf hc -c libraries/integer-simple/./GHC/Integer/Type.hs -o libraries/integer-simple/dist-install/build/GHC/Integer/Type.o
ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 7.7.20121205 for i386-unknown-nto-qnx):
	expectJust initTcInteractive

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

make[1]: *** [libraries/integer-simple/dist-install/build/GHC/Integer/Type.o] Error 1
make: *** [all] Error 2
}}}
",singpolyma
2,7534,18,pho@…,allocateRegsAndSpill: Cannot read from uninitialized register,Compiler,7.7,7.8.1,,new,high,2013-04-12T15:01:10-0700,"Building git HEAD on linux-powerpc64 and I get:

{{{
ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 7.7.20121227 for powerpc-unknown-linux):
        allocateRegsAndSpill: Cannot read from uninitialized register
    %vI_na5b
}}}
",erikd
2,7787,18,pho@…,modifyMVar does not restore value if callback returns error value,libraries/base,7.7,7.8.1,,new,high,2013-04-13T06:50:38-0700,"`modifyMVar` is currently implemented as follows:

{{{
modifyMVar :: MVar a -> (a -> IO (a,b)) -> IO b
modifyMVar m io =
  mask $ \restore -> do
    a      <- takeMVar m
    (a',b) <- restore (io a) `onException` putMVar m a
    putMVar m a'
    return b
}}}

The problem is that it forces the `(a',b)` outside of the exception handler.  If forcing this throws an exception, `putMVar` will not be called, and a subsequent `withMVar` or similar will hang.  Example:

{{{
> import Control.Concurrent.MVar
> mv <- newMVar 'x'
> modifyMVar mv $ \_ -> return undefined
*** Exception: Prelude.undefined
> withMVar mv print
-- hang --
}}}

Perhaps we can fix it like this:

{{{
-     (a',b) <- restore (io a) `onException` putMVar m a
+     (a',b) <- restore (io a >>= evaluate) `onException` putMVar m a
}}}",joeyadams
2,7830,18,pho@…,Error: operand out of range,Compiler,7.7,7.8.1,,new,high,2013-06-15T18:55:45-0700,"Compiling on linux-powerpc and linux-powerpc64 I get:

{{{
""inplace/bin/ghc-stage1"" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -Werror -Wall \
   -H64m -O0    -package-name time-1.4.0.2 -hide-all-packages -i -ilibraries/time/.  \
   -ilibraries/time/dist-install/build -ilibraries/time/dist-install/build/autogen \
   -Ilibraries/time/dist-install/build -Ilibraries/time/dist-install/build/autogen \
   -Ilibraries/time/include   -optP-DLANGUAGE_Rank2Types -optP \
   DLANGUAGE_DeriveDataTypeable -optP-DLANGUAGE_StandaloneDeriving -optP-include \
   -optPlibraries/time/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 \
   -package deepseq-1.3.0.2 -package old-locale-1.0.0.5 -Wall -XHaskell2010 -XRank2Types \
   -XDeriveDataTypeable -XStandaloneDeriving -XCPP -O2 -O -dcore-lint \
   -fno-warndeprecated-flags  -no-user-package-db -rtsopts -fno-warn-unused-do-bind \
   -fno-warn-deprecations -fno-warn-unused-imports -fno-warn-identities     -odir \
   libraries/time/dist-install/build -hidir libraries/time/dist-install/build -stubdir \ 
   libraries/time/dist-install/build  -dynamic-too -c libraries/time/./Data/Time/Format.hs \
   -o libraries/time/dist-install/build/Data/Time/Format.o -dyno \
   libraries/time/dist-install/build/Data/Time/Format.dyn_o
/tmp/ghc2806_0/ghc2806_1.s: Assembler messages:

/tmp/ghc2806_0/ghc2806_1.s:51766:0:
     Error: operand out of range (0x000000000000adf8 is not between 0xffffffffffff8000 and 0x0000000000007fff)

/tmp/ghc2806_0/ghc2806_1.s:51798:0:
     Error: operand out of range (0x000000000000ad90 is not between 0xffffffffffff8000 and 0x0000000000007fff)

/tmp/ghc2806_0/ghc2806_1.s:51830:0:
     Error: operand out of range (0x000000000000ad28 is not between 0xffffffffffff8000 and 0x0000000000007fff)

/tmp/ghc2806_0/ghc2806_1.s:51908:0:
     Error: operand out of range (0x000000000000ac1c is not between 0xffffffffffff8000 and 0x0000000000007fff)
}}}

",erikd
2,4374,18,pho@…,Remove in-tree gmp,Build System,7.1,7.8.1,igloo,new,high,2012-06-28T10:21:05-0700,"We already have the binary GMP DLL for Windows in the GHC tree. We should add the binary GMP dev stuff too, and then get rid of the in-tree GMP source. That would reduce build times, and simplify the build system.

I'm assuming installing GMP on other non-Windows OSes is not painful. We probably want to point to a framework for OS X users to use.
",igloo
2,7017,18,pho@…,"Rethink need for tarballs under ""friendly"" environment",Build System,7.4.2,7.8.1,,new,high,2013-02-07T07:04:20-0800,"I just compiled GHC from git.

I am amazed that one needs to download extra 200 MiB of tarballs and 100 MiB of libraries to compile GHC. The tarballs directory essentially only includes a Perl and a MinGW binary. Is this really needed for anything if not building under environments like Windows where getting that might be difficult?

It would certainly be nice to rethink the building system as to shrink the number of additional MiB's one needs to download to make the compiler work.",FUZxxl
3,5645,18,pho@…,Sharing across functions causing space leak,Compiler,7.2.1,7.6.2,,new,normal,2012-09-12T04:12:06-0700,"I have two test functions in code that both have a lazy list declared like this:

{{{
  let elements = [0 .. someBigInt]
}}}

If, from main, I run both of them, the compiler decides to share this list among them. In effect the memory is exhausted.

If only one function is called, the memory used is constant and low.

The workaround is to declare on of them like this:

{{{
  let elements = [0] ++ [1 .. someBigInt]
}}}

But this is very ugly.

What worries me most is that this is very non-obvious behaviour: if the list is declared locally inside a function, the compiler shouldn't (?) share it between two functions. It feels wrong.

If one of the functions is declared in different module, this behavior disappears. Seems like CSE is not done across modules boundaries.

Another workaround (tested) is to disable CSE with -fno-cse switch. You can test it works with ""make workaround"". The bug can be tested with ""make bug"".

The compiler behaves this way across the versions. I've tested 6.12.3, 7.0.2, 7.0.3, 7.0.4, 7.2.1, 7.2.2. 

My platform should be irrelevant, but for the sake of completeness:

{{{
Linux raptor 3.1.0-4-ARCH #1 SMP PREEMPT Mon Nov 7 22:47:18 CET 2011 x86_64 Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz GenuineIntel GNU/Linux
}}}

The code for reproducing is attached. Again, run it with ""make bug"" or simply ""make"".

I'm experimenting with high-performance FIFO queues. The implementation attached is quite potent, capable of processing 40M messages / second on my machine in one-producer one-consumer case.",tener
3,5898,18,pho@…,ghc: internal error: Invalid Mach-O file,Compiler,7.0.4,7.6.2,,new,normal,2012-09-12T04:12:11-0700,"I am running Mac OS 10.5.8 on a PowerPC processor.

{{{
$ cabal --version
cabal-install version 0.10.2
using version 1.10.2.0 of the Cabal library 
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.4
$ machine
ppc7450
}}}

`cabal install yesod-core` fails with

{{{
Loading package wai-logger-0.1.4 ... linking ... ghc: internal error: Invalid Mach-O file:Address out of bounds while relocating object file
    (GHC version 7.0.4 for powerpc_apple_darwin)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}",jeffshaw
3,5966,18,pho@…,getAppUserDataDirectory does not respect XDG specification,libraries/directory,7.4.1,7.6.2,,new,normal,2012-09-12T04:12:13-0700,"getAppUserDataDirectory function from System.Directory module returns path to a dot-dir under home directory. This swamps home with many hidden directories, when there are many applications installed. There is [http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html XDG specification] for this situation, which suggests using $XDG_DATA_HOME environment variable.

So, getAppUserDataDirectory should behave approximately like this when $XDG_DATA_HOME is set:
{{{
getAppUserDataDirectory appName = do
    path <- getEnv ""XDG_DATA_HOME""
    return (path++'/':appName)
}}}
",ordcoder
3,5982,18,pho@…,Incorrect dynamic library name in OSX,libraries/base,7.4.1,7.6.2,,new,normal,2012-09-12T04:12:13-0700,"When building a simple program that is built using -dynamic, the resulting executable fails with the following error:

/Users/ian/zz64/ghc-7.4.1/libffi/build/inst/lib/libffi.5.dylib
  Referenced from: /usr/local/lib/ghc-7.4.1/libHSrts-ghc7.4.1.dylib
  Reason: image not found
[1]    90849 trace trap

The workaround in this case is to execute the following two commands:

otool -id /usr/local/lib/ghc-7.4.1/libffi.dylib /usr/local/lib/ghc-7.4.1/libffi.dylib

install_name_tool /usr/local/lib/ghc-7.4.1/libHSrts-ghc7.4.1.dylib -change /Users/ian/zz64/ghc-7.4.1/libffi/build/inst/lib/libffi.5.dylib /usr/local/lib/ghc-7.4.1/libffi.dylib


which is to say that the library  at /usr/local/lib/ghc-7.4.1/libffi.dylib  is identified as being /Users/ian/zz64/ghc-7.4.1/libffi/build/inst/lib/libffi.5.dylib which causes the linker to fail.





",r0ml
3,5983,18,pho@…,Libraries installed in wrong place,libraries/base,7.4.1,7.6.2,,new,normal,2012-09-12T04:12:13-0700,"All of the installed libraries are placed in  /Library/Frameworks/GHC.framework/Versions/7.4.1-x86_64/usr/lib/ghc-7.4.1  by the installation package.

However, all of the dylib files report an otool -D of the form  /usr/local/lib/ghc-7.4.1/...

The workaround is to create a link from /usr/local/lib/ghc-7.4.1 to /Library/Frameworks/GHC.framework/Versions/7.4.1-x86_64/usr/lib/ghc-7.4.1

However, the installer should either create this link, or (better) invoke   otool -id as part of the installation process and set the correct dylib path for all the dylibs.
",r0ml
3,7388,18,pho@…,CAPI doesn't work with ghci,GHCi,7.6.1,7.6.2,igloo,new,normal,2012-11-19T18:13:53-0800,"{{{
$ ghc -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history T4012 --interactive -ignore-dot-ghci   
GHCi, version 7.7.20121101: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 3] Compiling T4012_B          ( T4012_B.hs, interpreted )

ByteCodeLink: can't find label
During interactive linking, GHCi couldn't find the following symbol:
  ghczuwrapperZC0ZCmainZCT4012zuBZCprintf
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session.  Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
  glasgow-haskell-bugs@haskell.org

> 
}}}
",igloo
3,7373,18,pho@…,When building GHC: Failed to load interface for `GHC.Fingerprint',libraries/base,7.6.1,7.8.1,,new,normal,2013-06-17T15:43:03-0700,"when doing a build with THREADS=1, we are getting
things like:
{{{
inplace/bin/ghc-stage1 [...] -c libraries/time/./Data/Time/Calendar/Days.hs [...]
/home/ian/ghc/git/ghc/libraries/base/dist-install/build/Data/Typeable/Internal.dyn_hi
Declaration for mkTyConApp
Unfolding of Data.Typeable.Internal.mkTyConApp:
  Failed to load interface for `GHC.Fingerprint'
  Perhaps you haven't installed the ""dyn"" libraries for package `base'?
  Use -v to see a list of the files searched for.
/home/ian/ghc/git/ghc/libraries/base/dist-install/build/Data/Typeable.dyn_hi
Declaration for mkTyCon
Unfolding of Data.Typeable.mkTyCon:
  Can't find interface-file declaration for variable GHC.Fingerprint.fingerprintString
    Probable cause: bug in .hi-boot file, or inconsistent .hi file
    Use -ddump-if-trace to get an idea of which file caused the error
}}}

(we only have Fingerprint.dyn_hi-boot). GHC still exits successfully, however.
",igloo
3,7379,18,rrnewton@…,rangeTest test fails on Windows,libraries/random,7.6.1,7.8.1,,new,normal,2013-04-12T10:40:49-0700,"The `CWchar` type on Win32 is unsigned:
{{{
Prelude> minBound :: Foreign.C.Types.CWchar
0
Prelude> (-100) :: Foreign.C.Types.CWchar
65436
}}}
This causes the `rangeTest` test to fail:
{{{
CWchar R:  
Stderr:
rangeTest.exe: broke lower bound: 100
}}}

Ryan, could you take a look please?
",igloo
3,7672,18,pho@…,boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module,Compiler (Type checker),7.4.2,7.8.1,,new,normal,2013-04-13T04:35:40-0700,"In a recursive module (i.e. a module that transitively imports itself), the unique ""Name"" of an entity E declared in this module's boot file should be precisely the same as that of the corresponding E defined in the module. Right now GHC appears to treat them as separate entities. (In the module systems literature, this problem has been identified as the ""double vision problem"" [1, Ch 5] and in general has caused problems with implementations of recursive modules. Derek Dreyer and his coauthors have proposed a number of solutions [2], and so have Im et al. more recently in the context of OCaml [3].)

With that being said, the ''immediate'' problem here seems to be that GHC does not actually allow, in the implementing module, the import of its boot file's entities.

There are a couple related errors I can identify with, huzzah!, very small example programs. The crux of the example is that the module A defines a data type T which is essentially the typical Nat data type -- except that the recursive type reference in the successor constructor refers to the ""forward declaration's"" view of the type (in the boot file) rather than the local view of that data type T.

This first example shows that the boot file import is not actually making available the entities it declares:
{{{
module A where
  data T
}}}
{{{
module A where
  import {-# SOURCE #-} qualified A as Decl(T)
  data T = Z | S Decl.T
}}}
The Decl.T reference should have the exact same identity as the locally defined T reference; after tying the module knot, this data type should be the same as if we had defined it with a T instead of Decl.T. However, the entity name T does not even appear to be gotten from the import of the boot file:
{{{
A.hs:3:18: Not in scope: type constructor or class `Decl.T'
}}}
In an earlier version of GHC I tested, 6.12.1, the error message lies on the import statement:
{{{
A.hs:2:44: Module `A' (hi-boot interface) does not export `T'
}}}

In the next example, with the same boot file, we see that the mechanism that checks whether the implementation matches the boot file fails to see the two ""views"" of T as the same. (Note that I changed the definition of T here to make the previous error go away.)
{{{
module A(Decl.T(..)) where
  import {-# SOURCE #-} qualified A as Decl(T)
  data T = Z | S T
}}}
Since Decl.T should point to the same entity as T, the export statement should have the same effect as if it were instead ""(T(..))"". However, GHC again cannot make sense of the reference ""Decl.T"" and then complains that the boot file's T is not provided in the implementation:
{{{
A.hs:1:10: Not in scope: type constructor or class `Decl.T'

<no location info>:
    T is exported by the hs-boot file, but not exported by the module
}}}
(Making the export list empty shows this second error message only.)

Altering this second example by omitting the alias on the import, and by changing the T reference in the type's definition to A.T, results in a well-typed module:
{{{
module A(A.T(..)) where
  import {-# SOURCE #-} qualified A(T)
  data T = Z | S A.T
}}}

A final example shows that, in a module that is ''not'' the implementing module, entities defined in the boot file are imported as one would expect! In the following example, we insert a module B, in between A's boot file and A's implementation, which merely passes along the boot file's view of T.
{{{
module A where
  data T
}}}
{{{
module B(Decl.T(..)) where
  import {-# SOURCE #-} qualified A as Decl(T)
  data U = U Decl.T
}}}
{{{
module A(T(..)) where
  import qualified B(T)
  data T = Z | S B.T
}}}
The error message here, again, lies in the reference B.T in A's implementation:
{{{
A.hs:3:18:
    Not in scope: type constructor or class `B.T'
    Perhaps you meant `A.T' (line 3)
}}}
Notice, however, that the reference to Decl.T in the B module is perfectly well-formed.

I suspect that the general problem lies with double vision, and that the more immediate problem--whereby imports of boot file entities from their implementing modules fail--is merely the manifestation of that.

In the above, wherever I have suggested an intended semantics, I refer primarily to the state of the art in recursive modules systems. A perhaps more pressing justification, however, is that both the Haskell language report and Diatchki et al.'s specification of the module system [4] (seem to) corroborate that intended semantics.

Your friend in the recursive module swamp,[[BR]]
Scott Kilpatrick

----

References

[1] Derek Dreyer. ''[http://www.mpi-sws.org/~dreyer/thesis/main.pdf Understanding and Evolving the ML Module System]'', PhD thesis, 2005.[[BR]]
[2] Derek Dreyer. ''[http://www.mpi-sws.org/~dreyer/courses/modules/dreyer07.pdf A Type System for Recursive Modules]'', ICFP 2007.[[BR]]
[3] Hyeonseung Im, Keiko Nakata, Jacques Garrigue, and Sungwoo Park. ''[http://dl.acm.org/citation.cfm?doid=2048066.2048141 A syntactic type system for recursive modules]'', OOPSLA 2011.[[BR]]
[4] Iavor S. Diatchki, Mark P. Jones, and Thomas Hallgren. ''[http://web.cecs.pdx.edu/~mpj/pubs/hsmods.html A formal specification of the Haskell 98 module system]'', Haskell 2002.",skilpat
3,7768,18,pho@…,"""untracked content"" in fresh clone of haskeline",Build System,7.7,7.8.1,igloo,new,normal,2013-04-13T06:26:22-0700,"This sequence of events happened today:

{{{
~> git clone http://darcs.haskell.org/ghc.git; cd ghc; ./sync-all --testsuite get
...
~/ghc> git status
# On branch master
# Changes not staged for commit:
#   (use ""git add <file>..."" to update what will be committed)
#   (use ""git checkout -- <file>..."" to discard changes in working directory)
#   (commit or discard the untracked or modified content in submodules)
#
#	modified:   libraries/haskeline (untracked content)
#
no changes added to commit (use ""git add"" and/or ""git commit -a"")
~/ghc> cd libraries/haskeline
~/ghc/libraries/haskeline> git status
# Not currently on any branch.
# Untracked files:
#   (use ""git add <file>..."" to include in what will be committed)
#
#	""tests/dummy-I\314\202\302\274I\314\202\302\261I\314\210\302\203/""
nothing added to commit but untracked files present (use ""git add"" to track)
}}}

It seems harmless, but I can't seem to make the problem go away. I'm on a Mac.",goldfire
3,7773,18,pho@…,Waiting on non-kqueue supported files on OS X,libraries/base,7.7,7.8.1,AndreasVoellmy,merge,normal,2013-05-05T20:14:39-0700,"Neither the old IO manager nor the new ""parallel"" IO manager properly handle waiting on files on Mac OS X when kqueue does not support the device type. PHO reported this on ghc-devs: http://www.haskell.org/pipermail/ghc-devs/2013-March/000798.html.

Here is the gist of it: the IO manager uses kqueue to wait on files on OS X. kqueue does not support all files. For example, on older versions of OS X (10.5.8) it cannot wait on tty devices and on even on 10.8.2 it cannot wait on /dev/random. 

Both the old and parallel IO managers suffered from the problem, but the consequences were slightly different. With the old IO manager the situation was treated as the file being ready, which would just cause the waiting thread to run again. The parallel IO manager changed things slightly and now it just throws an exception and terminates the program. So the behavior when this happens in the parallel IO manager is not acceptable.

",AndreasVoellmy
3,7492,18,"leather@…, ",Generic1 deriving: Can we replace Rec1 f with f :.: Par1?,Compiler,7.7,7.8.1,dreixel,new,normal,2013-04-12T14:01:17-0700,"It seems like `Rec1 f` is isomorphic to `f :.: Par1`. Is it possible and beneficial to replace the former with the latter and deprecate/remove `Rec1`?

 1. Currently, a parameter type is found in `Par1` or `Rec1`. By removing `Rec1`, there would be only one place for parameters. This simplifies generic functions.
 2. It is in the interest of reducing redundancy in the representation, something that appears to be consistent with the design of the representation types (e.g. using the same type for multiple meanings).",spl
3,7741,18,shelarcy@…,Add SIMD support to x86/x86_64 NCG,Compiler,7.7,7.8.1,,new,normal,2013-04-13T05:41:50-0700,"ghc-7.7.20130301 has SIMD support. But only LLVM backend supports SIMD currently. If we want to use SIMD, we should use LLVM backend. I request to add SIMD support to x86/x86_64 NCG.",shelarcy
3,1530,18,mnislaih@…,debugging :steps inside TH spliced code need to be bypassed,GHCi,6.7,_|_,,new,normal,2013-01-22T16:06:56-0800,See test dynbrk005 for an example,mnislaih
3,2031,18,pho@…,relocation overflow,Compiler,6.8.2,_|_,,new,normal,2009-12-15T00:05:40-0800,"I've created a statically linked ghc-6.8.2 for PPC Mac OS 10.4 (Tiger).
http://www.dfki.de/sks/hets/mac/versions/ghc-6.8.2-powerpc-apple-darwin-static-libs.tar.bz2

When linking our big hets binary after compilation with optimization I get millions (actually 34999 lines) of entries like:

{{{
/usr/bin/ld: PGIP/XMLparsing.o relocation overflow for relocation entry 63 in section (__TEXT,__text) (displacement too large)
...
/usr/bin/ld: SoftFOL/Sign.o relocation overflow for relocation entry 45280 in section (__TEXT,__text) (displacement too large)
collect2: ld returned 1 exit status
make: *** [hets] Error 1
}}}

I had such messages before and got rid of them by rearranging code and imports (just by wild guesses, a strategy would be helpful). It is sort of a known (Apple PPC) deficiency (and I misuse this ticket to document it here).

Linking works fine after compilation without optimization or when linking against GMP and GNUreadline frameworks using my other binary distribution.
",maeder
3,7080,18,tkn.akio@…,Make RULES and SPECIALISE more consistent,Compiler,7.4.2,_|_,,new,normal,2013-04-23T21:23:53-0700,"This [http://www.haskell.org/pipermail/glasgow-haskell-users/2012-July/022580.html glasgow-haskell-users email thread] describes the inconsistency between RULES and SPECIALISE pragmas. Consider
{{{
module Test where

import Data.Monoid
import Control.Monad.Writer.Strict

f :: Monad m => a -> m a
f = return

g :: Monoid w => a -> Writer w a
g = return

{-# RULES ""f->g"" f = g  #-}

{-# SPECIALISE f :: Monoid w => a -> Writer w a #-}
}}}
Here, the SPECIALISE pragma is accepted, but the RULE is rejected thus:
{{{
    Could not deduce (Monoid w) arising from a use of `g'
    from the context (Monad (WriterT w Identity))
      bound by the RULE ""f->g"" at Foo.hs:14:3-14
    Possible fix: add (Monoid w) to the context of the RULE ""f->g""
    In the expression: g
    When checking the transformation rule ""f->g""
}}}
Rejecting the RULE is quite right.  On the LHS you have an application
{{{
    f (WriterT w Identity) d
  where d :: Monad (WriterT w Identity)
}}}
Recall that `Writer w = WriterT w Identity`.  For the rewrite to work you have to rewrite this to
{{{
    g w d'
  where
    d' :: Monoid w
}}}
Well, how can you get a `Monoid w` dictionary from a `Monad (WriterT w Identity)`?

I was surprised that the SPECIALISE pragma worked, but here's what it does (you can see with -ddump-rules):
{{{
==================== Tidy Core rules ==================== ""SPEC Foo.f"" [ALWAYS]
    forall (@ a) (@ w) ($dMonoid :: Data.Monoid.Monoid w).
      Foo.f @ a
            @ (Control.Monad.Trans.Writer.Strict.WriterT
                 w Data.Functor.Identity.Identity)
            (Control.Monad.Trans.Writer.Strict.$fMonadWriterT
               @ w
               @ Data.Functor.Identity.Identity
               $dMonoid
               Data.Functor.Identity.$fMonadIdentity)
      = Foo.f_f @ a @ w $dMonoid
}}}
Ah!  This rule will only match if the LHS is exactly
{{{
f (WriterT w Identity) ($fMonadWriterT w Identity dm $fMonadIdentity)
}}}
So it's a nested pattern match.  That makes the LHS match less often; namely only when the dictionary argument to `f` is an application of `$fMonadWriterT`, the function that arises from the instance decl
{{{
    instance (Monoid w, Monad m) => Monad (WriterT w m) where
}}}
In exchange for matching less often, we now do get access to the `(Monoid w)` argument.

It is odd that this is inconsistent.  Here is why. For a RULE, we must have a way to rewrite the LHS to an arbitrarily complicated RHS.  For a SPECIALISE pragma
{{{
    SPECIALISE f :: spec_ty
where f's type is
    f :: poly_ty
}}}
we simply ask whether `poly_ty` is more polymorphic than `spec_ty`; that is, whether `f` can appear in a context requiring a value of type `spec_ty`. If so, we see what arguments `f` would need to do that, and that's the LHS pattern.

But
 * It's odd that the behaviour is inconsistent
 * The SPECIALISE rule is pretty fragile, beause it'll only match if the argument dictionary is constructed exactly as shown.

It's not clear to me what, if anything, to do about this, but this ticket records the issue.


",simonpj
3,750,18,pho@…,"Set -M, -H, -c and other memory-related values based on available virtual/physical memory",Runtime System,6.4.1,_|_,,new,normal,2009-11-16T05:06:51-0800,"From John Meacham:

  perhaps if `-M` is not otherwise set, {{{getrlimit(RLIMIT_AS,..)}}} could be
  called and the maximum heap size set to just under that, since it is the
  point that the OS will forcefully kill the program anyway.

Ravi Nanavati would like to be able to set the value to a percentage of physical RAM, e.g. `prog +RTS -H256m -M95% -RTS'.

Bulat Ziganshin would like to be able to do the same with `-c`.",simonmar
3,881,18,pho@…,Improve space profiling for references,Profiling,6.4.2,_|_,,new,normal,2013-02-22T02:19:31-0800,"GHC's great space profiling tools don't appear to be much help when your
leaked memory is stored in references (IORefs, StablePtrs, etc).  I had
a real-life case where the allocation profile showed me where the leaked
data came from, and I could guess that it was being held by some
reference, but I couldn't tell which one.  Retainer set profiling showed
a big suspicious entry for ""SYSTEM"", but I couldn't find any way to
pinpoint the problem.  (It ended up being a missing freeStablePtr in
hsgnutls, found by code inspection.)

Here's a contrived example that just allocates a bunch of IORefs:
{{{
    import Control.Monad
    import Data.IORef

    main = repeatM (newIORef [1,2,3])
    repeatM io = liftM2 (:) io (repeatM io)
}}}
Retainer set profiling shows everything in ""SYSTEM"".  None of the other
profiling methods say anything interesting either.  What I'd like to
get, I think, is (1) your memory is being held in IORefs (2) allocated
by this cost center and (3) being retained by this cost center.  I guess
I'm looking for something like a memory profiler for a traditional
language.  

Andrew Pimlott

Simon Marlow comments: ""The relevant predicate ""is retainer"" is pretty much built into the retainer profiler, and it returns true only for thunks if I recall correctly.  Being able to tweak this, or maybe just install a better default would be an improvement.",simonpj
3,3215,18,rrnewton@…,Valgrind support,Runtime System,6.10.3,_|_,,new,normal,2012-03-26T12:29:21-0700,"This is based on code in gtk2hs.
{{{
$ valgrind -q ./finalizer_queue

finalizer_queue: internal error: stg_ap_v_ret
    (GHC version 6.10.3 for i386_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Killed
}}}
Unfortunately this test doesn't crash without Valgrind.

My guess is that this bit is the problem:
{{{
    finalizer <- fixIO $ \dPtr -> mkThunk $ do
        freeHaskellFunPtr callback
        freeHaskellFunPtr dPtr
}}}
Perhaps the documentation should say not to do this?",cmcq
4,2161,18,pho@…,finaliser of a ForeignPtr called while references from unreachable threads exist,Runtime System,6.8.2,7.6.2,,new,low,2012-09-12T04:12:15-0700,"I believe that I've managed to distill a crash which has been driving
me crazy for a few days into a short enough test case (22 lines) that
it might be useful.

In short: the threaded RTS will call the finialiser of a ForeignPtr
while an exception handler still holds a reference to it:

{{{
% ghc -make fptest.hs cbits.c -threaded
[1 of 1] Compiling Main             ( fptest.hs, fptest.o )
Linking fptest ...
% ./fptest
New object getting created: 66f010
Finaliser getting called for 66f010
Use called for 66f010

}}}

I'm hoping that this is useful to someone who knows the RTS.

Cheers,",agl
4,3782,18,rl@…,"Data Parallel ""Impossible happened"" compiler error",Data Parallel Haskell,6.12.1,7.6.2,benl,new,low,2012-10-14T20:28:18-0700,"When I attempted to compile my vectorized code , I got the following message:
{{{
ghc -c -Odph -fcpr-off -fdph-seq newprop.hs
ghc: panic! (the 'impossible' happened)
  (GHC version 6.12.1 for i386-apple-darwin):
	sumTyCon 11

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}
",guest
4,4366,18,pho@…,in-tree GMP build problem with shared libraries,Build System,6.13,7.6.2,,new,low,2012-09-12T04:12:30-0700,"Reported by  Vivian McPhail <haskell.vivian.mcphail@gmail.com> on glasgow-haskell-users:

{{{
Trying to build rc1 from source

linux x86_64
BuildFlavour = perf

It seems that the -fPIC flag is set, but an error still occurs (
/usr/bin/ld: libraries/integer-gmp/gmp/objs/abs.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC
)

""inplace/bin/ghc-stage1"" -fPIC -dynamic  -O -H64m    -package-name base-4.3.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include   -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.2.0.0 -package integer-gmp-0.2.0.2 -package rts-1.0  -package-name base -XMagicHash -XExistentialQuantification -XRank2Types -XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances -XStandaloneDeriving -XPatternGuards -XEmptyDataDecls -XNoImplicitPrelude -XCPP -no-user-package-conf -rtsopts -O2 -XGenerics -fno-warn-deprecated-flags     -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf dyn_hi -osuf  dyn_o -hcsuf dyn_hc -c libraries/base/./Data/Typeable.hs-boot -o libraries/base/dist-install/build/Data/Typeable.dyn_o-boot
/usr/bin/ld: libraries/integer-gmp/gmp/objs/abs.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC
libraries/integer-gmp/gmp/objs/abs.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[1]: *** [libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.2-ghc7.0.0.20100924.so] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2
}}}",simonmar
4,5062,18,pho@…,Patch: Debug output for OS X linker and coding standard upgrades,Runtime System,7.0.3,7.6.2,,new,low,2012-09-12T04:13:26-0700,"This ticket is to track this patch:
{{{
Mon Mar 21 17:02:34 EDT 2011  gwright at antiope.com
  * Debug output for OS X linker and coding standard upgrades
  
  This long an invasive patch tidies up the OS X linker and
  adds copious debugging output.  If ghci is invoked with +RTS -Dl -RTS,
  the result of every relocation and external symbol lookup is
  dumped in gory detail.  The resulting output is long, more than
  60 MB when starting ghci, even if no programs or packages are
  specified, but is very useful when hunting linker bugs.
  
  The coding standard changes are mostly to impose uniform whitespace
  convertions and to use curly braces even for one line if/else statement
  bodies.  I've been burned by lack of those a few times.
}}}

http://www.haskell.org/pipermail/cvs-ghc/2011-March/060538.html
",igloo
4,3699,18,eir@…,Wildcards in type functions,Compiler,6.10.4,7.6.2,,new,low,2012-09-12T04:12:19-0700,"I would like to be able to use wildcards in type synonym family instances, so that I can write:

{{{
type instance ErrorAlg (f :>: _) e a = ErrorAlg f e a
}}}
",MartijnVanSteenbergen
4,4222,18,sergueyz@…,Template Haskell lets you reify supposedly-abstract data types,Compiler,6.12.3,7.6.2,,new,low,2012-09-12T04:12:28-0700,"Serguey Zefirov writes ([http://www.haskell.org/pipermail/haskell-cafe/2010-July/079802.html on Haskell cafe]) ""Data.Map.Map and Data.Set.Set are exported abstractly, without exposing knowledge about their internal structure.

I cannot directly create my own class instances for them because of that. But I found that I can write Template Haskell code that could do that - those data types could be reified just fine.""  

Good point.  It's not quite clear what a better design should be.  Haskell controls data abstraction by whether or not the constructors of the data type are exported.  But they might be exported by the module that ''defined'' them, but ''not'' to ""clients"" of the data type.  So the data type is abstract to some importers but concrete to others.

So when should TH let you reify the representation of a data type?  Maybe it should let you do so iff
  * The data constructors of the data type are in scope (somehow) at the reification site
So, to take an example:
{{{
module Conc( T(..), Blah(..) ) where
  data T = T1 | T2 Blah
  data Blah = A | B

module Abs( T, Blah ) where
  import Conc

module ReifyA where
  import Abs

  foo = reify ''T

module ReifyC where
  import Conc

  foo = reify ''T
}}}
So the `reify` in `ReifyC.foo` would ""see"" the data constructors of `T`, but not the one in `ReifyA`.

But this approach raises related questions. 

 * What if some, but not all, of `T`'s data constructors are in scope?

 * What if the data constructors are all in scope, but some mention a type that is not in scope?   For example, suppose type `Blah` is not in scope, but you reify `T`?

 * At the moment, when you reify a data type you get its `Dec`. But if `T` is abstract, what `Dec` can we give it?  Just giving it an empty constructor list seems wrong; after all, it might really ''be'' a zero-constructor data type. I suspect we may want a richer data type for `Info` (ie what `reify` returns).

All these require design thinking.  Does anyone want to lead that debate?  Otherwise things will probably stay as they are.

I've labelled this as a feature request, although it is a kind of bug, because of this design component.


",simonpj
4,5273,18,bos@…,error and undefined should print a location,Compiler,7.1,7.6.2,,new,low,2012-09-12T04:13:31-0700,"The Control.Exception.assert function has a very nice hack so it prints a location together with the message.  Could we please have that feature for 'error' and 'undefined' as well?

I just had the case where in one of 83 installed packages some idiot has an error message that just says 'dataTypeConstrs', which makes it very tedious to figure out what to fix.  Yes, I can recompile everything for profiling, but that takes another two hours, which is why I'd prefer location information.  (BTW, hbc had location info for those.)",augustss
4,3977,18,shelarcy@…,Support double-byte encodings (Chinese/Japanese/Korean) on Windows,libraries/base,6.13,7.8.1,batterseapower,new,low,2013-05-10T14:56:28-0700,"localeEncoding uses the console code page for text file encoding/decoding for single-byte encoding environment on Windows. But GHC.IO.Encoding.CodePage.Table doesn't have double-byte encodings (Chinese/Japanese/Korean), now. Its current state often causes problem on double-byte encoding environment.

 * http://hackage.haskell.org/trac/hackage/ticket/658
 * http://hackage.haskell.org/trac/hackage/ticket/659

I know we can solve problem by using hSetEncoding with utf8 or othere UTF-* encodings. But it's not good solution.

According to previous Windows patch, GHC.IO.Encoding.CodePage.Table doesn't support double-byte encodings because Windows' shared library support doesn't work.

 * http://www.haskell.org/pipermail/cvs-libraries/2009-September/011289.html
 * http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=packages/base;a=commitdiff;h=20090913022126-9f663-2bb505cf915b18313bf41a25853d9d13d7444feb.gz

{{{
Currently we do not support double-byte encodings (Chinese/Japanese/Korean), since
including those codepages would increase the table size to 400KB.  It will be
straightforward to implement them once the work on library DLLs is finished.
}}}

I think Windows' shared library support works now. Because #3879 is closed.

So, how about add supporting double-byte encodings (Chinese/Japanese/Korean) on Windows?",shelarcy
4,2625,18,aslatter@…,Unexpected -ddump-simpl output for derived Ord instance and UNPACKed fields,Compiler,6.8.3,_|_,,new,low,2008-10-31T03:23:00-0700,"In the following example, with either -O or -O2

In the derived Eq instance for A, in '==' nothing ever gets re-packed into a B constructor.

However in the derived Ord instance, in the 'compile' function the code from -ddump-simpl shows that the RHS of 'compare' is unpacked from the 'A' constructor only to be repacked in 'B' constructor and then passed on to a different function.

Is there any way we can do for 'compare' what was done for '==' ?

Thanks

{{{

module Bug where

data A = A {-# UNPACK #-} !B
 deriving (Eq, Ord)

data B = B {-# UNPACK #-} !Int
           {-# UNPACK #-} !Int
           {-# UNPACK #-} !Int
           {-# UNPACK #-} !Int
           {-# UNPACK #-} !Int
           {-# UNPACK #-} !Int
           {-# UNPACK #-} !Int
 deriving (Eq, Ord)

}}}",aslatter
4,2708,18,pho@…,Error message should suggest UnboxedTuples language extension,Compiler (Parser),6.9,_|_,,new,low,2008-11-27T20:14:40-0800,"If I compile this code:

{{{
module Foo where
import GHC.Integer

foo x y =
   case x `quotRemInteger` y of
    (# y, z #) -> 42
}}}

I get:

{{{
foo.hs:7:5: Parse error in pattern
}}}

It would be better if the error message suggested using {{{-XUnboxedTuples}}}.",tim
5,1487,18,adrien@…,unix package: test needed for getLoginName,libraries/unix,6.6.1,7.6.2,adrien,new,lowest,2013-01-22T09:06:02-0800,"I disabled the test for `getLoginName` in unix/tests/user001 because `getLoginName` cannot be called unless stdin is a terminal, which it isn't during an unattended build.  Perhaps we can test this by setting up a pseudoterminal first, but that requires the pty patches which aren't in yet.",simonmar
5,2370,18,pho@…,num009 fails on OS X 10.5?,Compiler,6.9,7.6.2,,new,lowest,2013-01-31T13:27:31-0800,"Running on an 8-core system based on Xeon 5400s.

Full error:

{{{
=====> num009(threaded2)
cd . && '/Users/mbolingbroke/Programming/Checkouts/ghc.working/compiler/stage2/ghc-inplace' -fforce-recomp -dcore-lint -dcmm-lint -Di386_apple_darwin  -dno-debug-output -o num009 num009.hs -O -threaded   >num009.comp.stderr 2>&1
cd . && ./num009  +RTS -N2 -RTS  </dev/null >num009.run.stdout 2>num009.run.stderr
Actual stdout output differs from expected:
--- ./num009.stdout.normalised	2008-06-17 09:55:40.000000000 +0100
+++ ./num009.run.stdout.normalised	2008-06-17 09:55:40.000000000 +0100
@@ -1 +1,31 @@
+sind
+-0.6452512852657808
+-0.7469218912594929
+(-5811906895766608,-53)
+(-6727674302302237,-53)
+sinf
+0.6565767
+-0.7710884
+(11015529,-24)
+(-12936717,-24)
+cosd
+0.7639704044417284
+-0.6649117899070088
+(6881233657531710,-53)
+(-5988992978518909,-53)
+cosf
+0.7542593
+0.63672805
+(12654371,-24)
+(10682524,-24)
+tand
+-0.8446024630198841
+1.123339821307656
+(-7607502675465106,-53)
+(5059072800651599,-52)
+tanf
+0.87049204
+-1.2110169
+(14604433,-24)
+(-10158746,-23)
 Done
*** unexpected failure for num009(threaded2)
}}}",batterseapower
5,3771,18,pho@…,haddock: internal error: evacuate: strange closure type 19269,Compiler,6.12.1,7.6.2,,new,lowest,2012-09-12T04:14:14-0700,"Here are the last few lines of `make` output
{{{
""rm"" -f libraries/unix/dist-install/build/libHSunix-2.4.0.0_p.a
(echo   libraries/unix/dist-install/build/cbits/HsUnix.p_o libraries/unix/dist-install/build/cbits/execvpe.p_o libraries/unix/dist-install/build/cbits/dirUtils.p_o     `/usr/bin/find libraries/unix/dist-install/build -name ""*_stub.p_o"" -print`; /usr/bin/find libraries/unix/dist-install/build/System/Posix_p_o_split libraries/unix/dist-install/build/System/Posix/DynamicLinker/Module_p_o_split libraries/unix/dist-install/build/System/Posix/DynamicLinker/Prim_p_o_split libraries/unix/dist-install/build/System/Posix/Directory_p_o_split libraries/unix/dist-install/build/System/Posix/DynamicLinker_p_o_split libraries/unix/dist-install/build/System/Posix/Env_p_o_split libraries/unix/dist-install/build/System/Posix/Error_p_o_split libraries/unix/dist-install/build/System/Posix/Files_p_o_split libraries/unix/dist-install/build/System/Posix/IO_p_o_split libraries/unix/dist-install/build/System/Posix/Process_p_o_split libraries/unix/dist-install/build/System/Posix/Process/Internals_p_o_split libraries/unix/dist-install/build/System/Posix/Resource_p_o_split libraries/unix/dist-install/build/System/Posix/Temp_p_o_split libraries/unix/dist-install/build/System/Posix/Terminal_p_o_split libraries/unix/dist-install/build/System/Posix/Time_p_o_split libraries/unix/dist-install/build/System/Posix/Unistd_p_o_split libraries/unix/dist-install/build/System/Posix/User_p_o_split libraries/unix/dist-install/build/System/Posix/Signals_p_o_split libraries/unix/dist-install/build/System/Posix/Signals/Exts_p_o_split libraries/unix/dist-install/build/System/Posix/Semaphore_p_o_split libraries/unix/dist-install/build/System/Posix/SharedMem_p_o_split -name '*.p_o' -print) | ""xargs""  ""/usr/bin/ar"" clqs  libraries/unix/dist-install/build/libHSunix-2.4.0.0_p.a
""inplace/bin/mkdirhier"" libraries/unix/dist-install/doc/html/unix/
""inplace/bin/ghc-cabal"" haddock dist-install libraries/unix --with-haddock=/Users/dbueno/Downloads/ghc-6.12.1/inplace/bin/haddock --with-ghc=/Users/dbueno/Downloads/ghc-6.12.1/inplace/bin/ghc-stage2  
Running Haddock for unix-2.4.0.0...
Preprocessing library unix-2.4.0.0...
Warning: The documentation for the following packages are not installed. No
links will be generated to these packages: ffi-1.0, rts-1.0
haddock: internal error: evacuate: strange closure type 19269
    (GHC version 6.12.1 for powerpc_apple_darwin)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
make[1]: *** [libraries/unix/dist-install/doc/html/unix/unix.haddock] Error 6
make: *** [all] Error 2
}}}
I did the following to build:
{{{
./configure --prefix=/usr/local/ghc-6.12.4
make
}}}

I'm on `Darwin power-mac-g5.local 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31 22:54:29 PDT 2009; root:xnu-1228.12.14~1/RELEASE_PPC Power Macintosh`.

What other information do you need?",dbueno
5,2737,18,mnislaih@…,add :tracelocal to ghci debugger to trace only the expressions in a given function,GHCi,6.8.3,7.6.2,,new,lowest,2012-09-12T04:14:04-0700,"As there is :steplocal, there should be also :tracelocal. It would keep history of evaluations within a given function. When an acces to a variable is needed it would be searched first in the selected expression and if not found the search would continue in the expressions from the trace history. If the value used would originate from the trace history it should be indicated so in the output: at the end or beginning of the output there would be the list of identifiers which values were taken from trace history. This would avoid the tedious task of searching the trace history manually and moreover it would limit the history to the interesting parts (so hopefully the current depth of 50 would be enough).

:tracelocal should take an optional argument which defines the function to trace. Similar options as for a breakpoint specification (:break command) would be fine. It might be usefull to associate the tracelocal trace with breakpoint and having an option to set it on for given breakpoint (in such a case it would be possible to add tracelocal flag for a breakpoint).

Note that the results from the trace history may not be from the expected scope but the same problem is with ""printf debugging"" which is an efficient way to debug Haskell programs now too. The list of identifiers which were taken from trace history (while evaluating an interactively entered expression) should be provided because of the posibility to get values from an unexpected scope. 

This should be a cheap way to make ghci debugger better than just plain ""printf debugging"", especially when used together with scriptable breakpoints (where one could script each breakpoint individually - not only all of them at once with :set stop). The best solution from user point of view would be just to provide access to all the variables which are in scope in a given expression (not just the free ones) but it is believed that it would introduce too much overhead.

Here is the url of the thread head where this proposal started to evolve:
http://www.haskell.org/pipermail/glasgow-haskell-users/2008-October/015840.html",phercek
5,2803,18,mnislaih@…,bring full top level of a module in scope when a breakpoint is hit in the module,GHCi,6.8.3,7.6.2,,new,lowest,2012-09-12T04:14:04-0700,"It should do something like {{{:module + *ModuleWhereBreakpointWasHit}}} and remove the added top level symbols of {{{ModuleWhereBreakpointWasHit}}} when we leave it.
The goal is so that the functions which are in scope when we hit a breakpoint are readily available for investigations of the values stored in the free variables of the selected expression.
This feature request is a consequence of the dicsussion in this ticket http://hackage.haskell.org/trac/ghc/ticket/2740#comment:4

... and a realated thing: When I do something like {{{:module + ModName}}} and later I do {{{:module + *ModName}}} then the non-exported symbols from {{{ModName}}} are not added into the scope.",phercek
5,2950,18,mnislaih@…,show breakpoint numbers of breakpoints which were ignored during :force,GHCi,6.10.1,7.6.2,,new,lowest,2012-09-12T04:14:06-0700,"Extend message ""*** Ignoring breakpoint"" (which is printed during :force evalutation) so that it contains basic information about the breakpoint ignored. Add at least the breakpoint number.",phercek
5,1600,18,pho@…,Optimisation: CPR the results of IO,Compiler,6.6.1,7.6.2,,new,lowest,2013-01-26T14:22:53-0800,"GHC currently cannot unbox the result of a function in the IO monad.  For example:

{{{
facIO :: Int -> IO Int
facIO n = if n < 2 then return 1 else do n' <- facIO (n-1); return (n*n')
}}}

the `Int` argument is unboxed fine, but not the result.  It ought to be possible to do this: the CPR analysis needs to somehow look inside the unboxed pair returned by IO-monadic code.",simonmar
2,7481,17,eir@…,Partially promoted data types,Compiler,7.6.1,7.8.1,,new,high,2012-12-05T07:26:48-0800,"Consider
{{{
{-# LANGUAGE DataKinds, PolyKinds #-}

data D a where
  D1 :: a -> D a
  D2 :: (a~Int) => D a
  D3 :: forall (a:k). Proxy a -> D b

}}}
Is `D` a promoted type? 

Well, `D1` is promotable, but `D2` is not because of constraints in its type, and neither is `D3` because it uses kind polymorphism.  It's a bit odd to promote only one of the three constructors, but that is what happens right now.

We should probably check for promotability of all data constructors, and promote all or none.  A bit of fiddling around is need to do this, so I'm opening a ticket.  It's not terribly pressing.
",simonpj
3,7962,17,timmaxw@…,"""ghc -e <invalid expression>"" should return non-zero exit status",GHCi,7.6.2,,,new,normal,2013-06-04T23:53:13-0700,"When GHC is run in expression-evaluation mode (i.e. with the ""-e"" flag) and the expression does not compile, GHC correctly prints an error message, but then exits with exit status 0. For example:

{{{
$ ghc -e foo

<interactive>:1:1: Not in scope: `foo'
$ echo $?
0
}}}

This is inconvenient for automated scripts that call GHC.
",timmaxw
3,5429,17,fischer@…,Docase notation as GHC extension,Compiler,,7.6.2,tomasp,new,normal,2012-09-12T04:12:03-0700,"Many monads provide additional combinators for ''parallel composition'', ''choice'' and ''aliasing''. In our Haskell Symposium 2011 paper (http://www.cl.cam.ac.uk/~tp322/papers/docase.html) we call a monad with these 3 additional combinators a '''joinad'''.

The monads that implement (some of) these three operations include:

  * '''Par monad''' for parallel programming implements ''parallel composition'' (run two computations in parallel) and ''aliasing'' (start computation and access the result in multiple other computations) and can be extended to support (non-deterministic) ''choice''
  * '''Parsers''' can implement ''parallel composition'' as an intersection of languages (parse the same input using multiple parsers), which is useful for encoding validation rules and ''choice'' (use the result of a first parser that succeeds).
  * '''Other monads''' that can be considered include the `Orc` monad (for concurrent orchestration) and the encoding of CHP (Communicating Haskell Processes).

The proposal is to implement the a GHC extension that allows the `docase` notation for working with ''joinads''. Using the `Par` monad as an example, the following snippet implements a function `all` which tests whether a predicate holds for all leaves of a tree:

{{{
all :: (a -> Bool) -> Tree a -> Par Bool

all p (Leaf v)           = return (p v)
all p (Node left right)  = 
  docase all p left, all p right of
    False, ?    -> return False
    ?, False    -> return False
    allL, allR  -> return (allL && allR)
}}}

The left and right sub-trees are processed in parallel (using ''parllel composition''). The special pattern `?` denotes that the corresponding computation does not have to complete in order for the clause to match. This means that the first two clauses implement short-circuiting behavior (and can match even if the other branch is still being processed).

The operations used by the desugaring are expected to have the following types:

 * `mzip :: m a -> m b -> m (a, b)`[[br]]This operation has been added by the recent patch that re-implements ''monad comprehensions'', so we can reuse it.
 * `morelse :: m a -> m a -> m a`[[br]]The operation has the same type as `mplus` from `MonadPlus`, but we require an operation that is left-biased. One possible option is to add `MonadOr` type class as suggested in http://www.haskell.org/haskellwiki/MonadPlus_reform_proposal.
 * `malias :: m a -> m (m a)`[[br]]The operation ""starts"" a computation and returns a handle for accessing the result. It has been used e.g. by the authors of the `Orc` monad. For many simpler monads, this can be implemented as monadic `return`.

===Feedback===
I would appreciate any feedback from GHC users and developers! In particular, here are some general, as well as more specific questions that I've heard in the past:

 * What existing monads can implement the interface? (I believe there are quite a few of them including `Par`, Parsers, `Orc`, CPH, but I'd love to know about more.)

 * What to do about monads that implement only some operations? Currently, the `malias` operation has default implementation. If a `docase` notation has just a single clause, then `morelse` is not required. If it has multiple clauses, each having just a single ''binding pattern'' (non `?`) then `mzip` is not required.

 * The laws - the paper includes detailed discussion about laws (e.g. why `mzip` should be symmetric and why `morelse` should have left-biase). Does the community agree with the laws, or do you suggest some changes?

 * Syntax seems to be a tricky question - the notation intentionally resembles `case`, but it takes a list of arguments (of type `m a1`, ..., `m an`), so it is not using ''tuple syntax''. Is there any better alternative?

 * Correspondence with ''monad comprehensions'' - the `docase` notation can express parallel composition in a similar way as ''monad comprehensions''. I think this parity is a good thing. However, it allows more expressivity in one direction (by adding choice) and less in another (no group/order by comprehensions). Do you think this is a good ballance?",tomasp
3,7398,17,bgamari@…,RULES don't apply to a newtype constructor,Compiler,7.6.1,7.8.1,,new,normal,2013-04-12T11:20:10-0700,"For some reason, RULES that involve a newtype constructor never seem to fire. The following program demonstrates the problem:

{{{
module Main where

newtype Foo a = Foo { unFoo :: a }
  deriving Show

foo :: a -> Foo a
foo = Foo

{-# RULES ""rule Foo""  forall v.  Foo v = error ""Foo"" #-}
{-# RULES ""rule foo""  forall v.  foo v = error ""foo"" #-}

main :: IO ()
main = do
    print (Foo ())
    print (foo ())
}}}

""rule foo"" fires, but ""rule Foo"" doesn't. The program prints

{{{
Foo {unFoo = ()}
D: foo
}}}

Note that this doesn't seem to affect selectors, only constructors.",shachaf
3,7413,17,me@…,runghc (runhaskell) should be able to reload code on editing,Compiler,7.6.1,7.8.1,,new,normal,2013-04-12T11:46:24-0700,"Hot code reloading on file edit is an incredibly useful feature for server development.

Right now several Haskell web frameworks are able to reload code on file edits, however there does not seem to be a simple way to use code reloader from one of them without finding yourself up to the neck in the framework.

It seems to me that the best thing what can be done is a flag to runghc / runhaskell:

{{{
runghc --reload MyServer.hs
}}}

It should watch for changes in the main file and all imported modules (or at least imported modules in the current folder).

A nice addition would be an ability to specify more files to watch

{{{
runghc --reload-watch *.some.weird.haskell.js  --reload MyServer.hs 
}}}

",va1en0k
3,472,17,merehap@…,Supertyping of classes,Compiler (Type checker),None,_|_,,new,normal,2012-06-30T23:50:19-0700,"see
[http://repetae.net/john/recent/out/supertyping.html Supertyping Suggestion for Haskell]

example:
{{{
class Num a <= Group a where
	(+) :: a -> a -> a 
	negate :: a -> a
}}}

apart from multiple inheritance, it could work like this:

{{{
import Prelude hiding ((+),negate)
import qualified Prelude ((+),negate)

class Group a where
	(+) :: a -> a -> a 
	negate :: a -> a

instance Num a => Group a where
	(+) = (Prelude.+)
	negate = Prelude.negate
}}}

- coeus_at_gmx_de",nobody
3,1791,17,iampure@…,heap overflow should generate an exception,Runtime System,6.8,_|_,,new,normal,2013-01-26T14:48:33-0800,"I want to use the -M option for the goals that are stated in the manual. 

{{{
./TestProgram +RTS -M5m -RTS 
}}}
Expected output:
{{{
Something like ""out of heap space""
}}}
Actual result:
{{{
Machine going into a state where it swaps memory 
}}}

This is the code for TestProgram: 
{{{
import Control.Monad.ST 
import Data.Array.ST
import Data.Array.MArray
import Data.Array.Base(unsafeNewArray_)
main = print (runST (do make_empty_table >> return ()))

make_empty_table::  ST s (STArray s (Int, Int) (Maybe ep))
make_empty_table = 
       unsafeNewArray_ ((1, 1), (16384, 16384))
}}}

This was tested with 6.9.20071018 on an athlon-xp, and confirmed by dcoutts also on x86-64 with ghc-6.8.0.20071015. 

",guest
3,1826,17,iampure@…,unable to list source for <exception thrown> should never occur,GHCi,6.8.1,_|_,,new,normal,2013-01-26T15:50:09-0800,"I get the very unhelpful ""unable to list source for <exception thrown>"". I would like to get one of the following two responses, the last one is best.  
{{{
Do this and that to list source
}}}
{{{
We currently cannot list source, because you did and that Do you still want to list source                although it requires to do that and that(for example automatically recompiling and reexecuting it until the same program point) [Y/n]?
}}}",guest
3,2895,17,bgamari@…,"Implement the ""Class System Extension"" proposal",Compiler,6.10.1,_|_,,new,normal,2012-02-28T20:30:57-0800,"See: http://haskell.org/haskellwiki/Class_system_extension_proposal

Executive summary:
   1.  Class and instance declarations would allow method implementations to be given for any methods in the class or any ancestor class.
   2. Whenever an instance declaration is visible there would always be a full set of instance declarations for all ancestor classes, by supplementing the set of explicitly given instance declarations that are visible in a module by automatically generated implicit instance declarations.
   3. The most specific method implementation would always be chosen (ie prefer an explicit instance method over a class method and prefer a subclass method to a superclass method)
   4. Modules would only export explicit instance declarations ",porges
3,3021,17,"SamB, hvr@…",A way to programmatically insert marks into heap profiling output,Profiling,6.10.1,_|_,,new,normal,2012-10-02T15:58:14-0700,"This would be useful for e.g. marking compiler phases.

Hmm, this would be more useful if the ""MARK"" record type had a string field...",SamB
4,4150,17,yairchu@…,CPP+QuasiQuotes confuses compilation errors' line numbers,Compiler (Parser),6.12.3,7.6.2,,new,low,2012-09-12T04:12:25-0700,"doing an #include of multi-line files inside QuasiQuotes makes GHC report wrong line numbers on errors occurring in normal code which is after the said #include.

{{{
myHtmlsTemplate = [$multiLineStr|
#include ""template.html""
|]

somethingElse :: NoSuchType
somethingElse = 7
}}}

The example code will fail compiling with: {{{Not in scope: type constructor or class `NoSuchType'}}}, but will not report the correct line number of the error.
",yairchu
4,4505,17,cathper@…,Segmentation fault on long input (list of pairs),Compiler,7.0.1,7.6.2,,new,low,2012-09-12T04:12:32-0700,"When compiling LongList.hs with
{{{
ghc --make LongList.hs
}}}
then running the output gives a segfault:
{{{
$ ./LongList
8595
Segmentation fault
}}}
It also segfaults with ghc 6.12.1 (without printing 8595) and with ghc 6.12.3.

On ghc 6.12.3 running on Mac OS 10.5, no segfault is seen. (I haven't tried much longer input, since it already eats up approx. 1.2 GB of RAM.)",cathper
4,4213,17,bgamari@…,LLVM: Add support for TNTC to LLVM compiler suite,Compiler (LLVM),6.13,7.6.2,dterei,new,low,2012-09-12T04:12:27-0700,"At the moment we handle TNTC in the LLVM backend in two different ways:

Linux/Windows: We use the GNU As subsections feature to order sections. Works very nicely. Slight hack in that we create special section names that contain comments. (Asm injection)

Mac: Mac assembler doesn't support the GNU As subsections feature, so we post-process the assembly code produced by llc.

Both these methods (especially Mac) are hacks. It would be better to extend LLVM to support the TNTC feature.",dterei
4,2204,17,marcot@…,Improve 'patterns not matched' warnings,Compiler,6.8.2,_|_,,new,low,2010-02-19T11:40:30-0800,"Compiling the following with `-fwarn-incomplete-patterns`:

{{{
module Asdf where

f :: String -> Int
f ""0"" = 0

g :: Int -> Int
g 0 = 0
}}}

Yields:

{{{
asdf.hs:4:0:
    Warning: Pattern match(es) are non-exhaustive
             In the definition of `f':
                 Patterns not matched:
                     []
                     (GHC.Base.C# #x) : _ with #x `notElem` ['0']
                     (GHC.Base.C# '0') : (_ : _)

asdf.hs:7:0:
    Warning: Pattern match(es) are non-exhaustive
             In the definition of `g':
                 Patterns not matched: GHC.Base.I# #x with #x `notElem` [0#]
}}}

Losing the 'GHC.Base' stuff along with the various octothorpes would make the error messages a lot nicer. Ideally it'd be something like `Patterns not matched: x where x `notElem` [0]` for the second case, for instance.",Deewiant
5,1853,17,chris@…,hpc mix files for Main modules overwrite each other,Code Coverage,6.8.1,7.6.2,AndyGill,new,lowest,2013-01-28T07:50:33-0800,"I have several programs, and hence several files that define Main modules, in the same directory.  I build each one with a ghc --make -o Progname.  When The hpc mix files describing the compiled modules are dumped in .hpc, the current Main.mix overwrites any previous Main.mix.  As a result, I can only get an hpc report from Progname.tix if Progname was the most recent binary to be compiled.
",guest
5,3055,17,merehap@…,Int / Word / IntN / WordN are unequally optimized,Compiler,6.11,7.6.2,,new,lowest,2012-09-12T04:14:08-0700,"A lot of thought has been put into optimizing usage of `Int`, but not all of these tweaks have been copied for usage of `Word`, and the specific-size versions of both have even fewer optimizations. The consequence is that switching from signed to unsigned, or from unspecified to specified size, can result in dramatic performance loss.

- builtin rules (`prelude/PrelRules`) cover `Int` and `Word`, but not sized alternatives

- `SPECIALI[SZ]E` pragmas cover `Int`, but little of the others. Try 
{{{
find libraries/ -name _darcs -prune -o -name *hs | 
  xargs grep SPECIAL | grep '\<Int\|\<Word'
}}}

- some instances have special cases for `Int`, but not for the others (for instance, the `Enum` instance for `Int` uses specialised `enumFromTo` code, the `Word` version uses generic code; `base/GHC/Enum.hs` and `base/GHC/Word.hs`)

- some `RULES` help optimizing the special cases for `Int` further (again, see the `Enum` instance for `Int` for an example)

See this thread [http://www.haskell.org/pipermail/glasgow-haskell-users/2009-February/016705.html ""Int vs Word performance?""] for more discussion.

related tickets: #2270, #3051",claus
5,2437,17,mjm2002@…,More accurate package dependencies,Package system,6.8.3,7.6.2,,new,lowest,2012-09-12T04:13:59-0700,"The problem we want to solve here is that there is currently no distinction between compile-time package dependencies and link-time package dependencies.  Often a compile-time dependency is also a link-time dependency, but there are two instances in which it might not be:

 * Template Haskell: some packages might be required for executing TH code at
   compile-time, but the compiled code doesn't require those packages to be
   linked in.

 * [wiki:Annotations]: we're considering allowing arbitrary attributes to be attached
   to declarations, where the attributes are compile-time Haskell expressions.
   The same issue as with TH crops up again here.

Currently we figure out which packages to link by looking at the (transitive closure of the) imports.  It would be better to look at the external references of the compiled code; some of the packages referred to by imports may not need to be linked.

Similarly, we should figure out the dependencies of a ``package`` by taking the union of the link-time dependencies of its compiled modules.  This means a small changes to Cabal.

None of this is particularly hard, and doesn't need any changes to the interface file format or package database: we just record fewer package dependencies than before.  The only tricky bit is traversing the code to figure out what the package dependencies should be.
",simonmar
2,5051,16,mechvel@…,Typechecker behaviour change,Compiler,7.0.2,7.2.1,,new,high,2012-05-21T15:43:48-0700,"From: http://www.haskell.org/pipermail/glasgow-haskell-users/2011-March/020116.html

The behaviour has changed (7.0.1 accepts it, 7.0.2 doesn't), but I'm not sure which behaviour is right.

I've put a cut-down (but not standalone) version of the offending module below. I believe the relevant steps are then:

{{{
The ct application means we need an instance for:
      Cast (ResidueI (Pol (ResidueE (UPol k))))
                     (Pol (ResidueE (UPol k)))

Need: Cast (ResidueI (Pol (ResidueE (UPol k))))
                     (Pol (ResidueE (UPol k)))
Have:     instance LinSolvRing a => Cast (ResidueI a) a

Now need: LinSolvRing (Pol (ResidueE (UPol k)))
Have:     instance EuclideanRing a => LinSolvRing (Pol a)

Now need: EuclideanRing (ResidueE (UPol k))
Have:     instance (EuclideanRing a, Ring (ResidueE a) )
                => EuclideanRing (ResidueE a)

Now need: EuclideanRing (UPol k)
Have:     instance Field a => EuclideanRing (UPol a)

Now need: LinSolvRing (UPol k)    (from the EuclideanRing class constraints)
Have:     instance EuclideanRing a => LinSolvRing (UPol a)  (Pol2_.hs:95)
And:      instance (LinSolvRing (Pol a), CommutativeRing a)
                => LinSolvRing (UPol (Pol a))

A different instance should be used depending on whether or not
    k = Pol x
(for some x).
}}}

With flags:
{{{
-XTypeSynonymInstances -XUndecidableInstances -XFlexibleContexts -XFlexibleInstances -XMultiParamTypeClasses -XOverlappingInstances -XRecordWildCards -XNamedFieldPuns -XScopedTypeVariables -fcontext-stack=30
}}}

{{{
module T_cubeext (cubicExt) where

import Prelude (undefined)
import DPrelude (ct)
import Categs (ResidueE)
import SetGroup ()
import RingModule (Field, FactorizationRing)
import VecMatr  ()
import Fraction ()
import Pol (Pol, UPol)
import Residue (ResidueI)
import GBasis  ()

cubicExt :: forall k . (Field k, FactorizationRing (UPol k))
         => k -> ()
cubicExt _ = undefined
 where unE :: ResidueI (Pol (ResidueE (UPol k)))
       unE  = undefined

       kToE :: Pol (ResidueE (UPol k)) -> ResidueI (Pol (ResidueE (UPol k)))
       kToE = ct unE
}}}
",igloo
2,5909,16,jwlato@…,Segfault with multi-threaded retainer profiling,Runtime System,7.4.1,7.6.2,simonmar,merge,high,2013-02-19T07:58:42-0800,"I see the following program often segfaults when compiled and run like this:

{{{
% ghc -threaded -O2 -prof -fprof-auto segfault.hs -rtsopts
[1 of 1] Compiling Main             ( segfault.hs, segfault.o )
Linking segfault ...
% ./segfault aaaaaaaaaaaaaaaaaaaaaaa +RTS -hr -N5 -V -A512K
# Segfaults, often within a minute.
}}}

It also seems to me that it segfaults more often/quickly when some other process is actively running on the same machine. I kept ""ghc -e 'last [1..]' +RTS -A13G"" running while making the test case. The machine I used has 4 cores, 8 HT threads and 16GB RAM.",akio
2,5361,16,targen@…,regSpill: out of spill slots!,Compiler,7.1,7.8.1,,new,high,2013-05-10T13:36:06-0700,"{{{
runghc ./Setup.hs build
Building SHA-1.5.0.0...
Preprocessing library SHA-1.5.0.0...
[1 of 1] Compiling Data.Digest.Pure.SHA ( Data/Digest/Pure/SHA.hs, dist/build/Data/Digest/Pure/SHA.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.2.0.20110728 for x86_64-unknown-linux):
	regSpill: out of spill slots!
       regs to spill = 2479
       slots left    = 2040

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
}}}
",markwright
2,5910,16,leather@…,Holes with other constraints,Compiler (Type checker),7.5,7.8.1,,new,high,2012-10-02T09:19:45-0700,"Hello. As can be seen on http://hackage.haskell.org/trac/ghc/wiki/Holes and http://www.haskell.org/pipermail/glasgow-haskell-users/2012-January/021670.html, we've been working on adding holes to GHC. I'm opening this ticket about a specific problem I've been having, and I hope someone has a suggestion of how to do it correctly.

As holes work quite similarly to implicit parameters (see the wiki-page for a comparison), we started out in the same way as implicit parameters. Typechecking of a hole generates a constraint (a new type of constraint), and the constraint solver will try to find the right type for each hole. The difference is that hole constraints never show up in a type, but their type is printed separately. This currently works correctly for simple typechecking, but it has some problems when other constraints are generated too. A simple example:

{{{
test :: String
test = show _h
}}}

Here, the {{{_h}}} denotes a hole named ""h"". If this function is defined like this inside a module it will currently fail:

{{{
test2.hs:2:8:
    No instance for (Show a0)
      arising from a use of `show'
    The type variable `a0' is ambiguous
    Possible fix: add a type signature that fixes these type variable(s)
    In the expression: show (_h)
    In an equation for `test': test = show (_h)
Failed, modules loaded: none.
}}}

The problem is that the {{{Show}}} constraint is still there. If the type signature is omitted and the monomorphism restriction off, we can see that the types found are:

{{{
Found the following holes: 
_h :: GHC.Show.Show a => a
...
test :: Show a => String
}}}

The problem is the {{{Show a}}} that is irrelevant to the actual type of {{{test}}}, but nevertheless it's there.


How do other approaches handle this?

'''undefined''':
{{{
test :: String
test = show undefined
}}}

Gives the same ambiguity error, even if the signature is omitted.

'''Implicit parameters''':
{{{
test = show ?h
}}}

This works, but generates the following type signature:

{{{
test :: (Show a, ?h::a) => String
}}}

So, as I'd want to use it, this is wrong. It has the right ingredients, but I'd want:

{{{
test :: (?h :: (Show a) => a) => String
}}}

For implicit parameters the difference doesn't matter too much, as implicit parameters are still parameters: they still show up in the type signature. A hole is not required to be a parameter, so it's more important that every constraint only shows up where it's necessary.

So the problem is that I don't know how to select from the constraints only those that are applicable to the expression/function itself, and those that apply to which of the holes. I've tried typechecking all of the holes first, but I don't know how to determine how to change the constraint set after that. If you need more information about how it currently works, or have any feedback on this approach, please let me know. I'm still quite unfamiliar with the architecture of GHC. :)

----

I'm attaching a patch against the master branch on git with my current work in case someone is interested in trying it. Note that the code generation is pretty much a stub and it will panic if you try to run a function with a hole. It will print the holes of an expression if you invoke {{{:t}}} (it doesn't currently print the holes when loading a module, but it should still print them with {{{:t}}} on a function from the module). Also, I do not recommend building stage 1 with this, as some packages have some issues. Easiest is to build stage 1 and the packages without these changes and then applying the patch and then building only stage 2.",xnyhps
3,4451,16,jwlato@…,Re-linking avoidance is too aggressive,Compiler,7.1,7.6.2,simonmar,new,normal,2012-09-12T04:12:00-0700,"I'm constantly annoyed by having to `rm` the binary when I want to relink with different options (`-rtsopts`, `-threaded`, etc.).  We only check the date of the binary against the date of the object files and relink if it is out of date, we should really check whether the options have changed or not too.

Similar problems exist in ordinary `.hs` recompilation (see #437), but the solutions will be different, so it makes sense to have a separate ticket.

One solution is to store information about what settings were in effect when linking in the binary, perhaps in a special section that isn't loaded during execution.  We already compile a C file during linking to support `-rtsopts`, so we could add some magic asm to it, and then use `objdump` during linking to extract the information from the existing binary if there is one.

",simonmar
3,6016,16,dagitj@…,"On Windows, runhaskell hits an error on UTF-8 files with a BOM",Compiler (Parser),7.0.4,7.6.2,,new,normal,2013-03-02T21:16:00-0800,"The file

{{{
#!/usr/bin/env runhaskell
main = putStrLn ""Hello, world!""
}}}
works on Windows as expected:

{{{
C:\Temp>runhaskell hello.hs
Hello, world!
}}}
However, if the file is saved as UTF-8 with a BOM (Windows Notepad, for example, sometimes adds this BOM to files), an error occurs:

{{{
C:\Temp>runhaskell hello2.hs

hello2.hs:1:1: parse error on input `#!/'
}}}

I'm using the Haskell Platform 2011.4.0.0.

I believe that runhaskell/runghc should handle the presence of a BOM correctly; some Windows programs insert a BOM unbeknownst to the user.

This behaviour was observed on Windows XP (32-bit) and Windows 7 (32-bit and 64-bit).
",vsajip
3,5942,16,clint@…,implement POSIX confstr() in System/Posix/Unistd.hsc,libraries/unix,7.4.1,7.6.2,,new,normal,2012-09-12T04:12:13-0700,,clint
3,7245,16,jwlato@…,INLINEing top-level patterns causes ghc to emit 'arity missing' traces,Compiler,7.6.1,7.8.1,,new,normal,2012-10-20T16:00:20-0700,"When an INLINE pragma is specified on a pattern, ghc-7.6.1 shows some internal trace messages.

{{{
module Foo where

{-# INLINE widths #-}

widths :: [Int]
widthMonth, widthYear :: Int

widths@[widthMonth, widthYear] = [1,2]
}}}

{{{
~/Downloads$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.6.1
~/Downloads$ ghc Foo.hs -O
[1 of 1] Compiling Foo              ( Foo.hs, Foo.o )
makeCorePair: arity missing widths{v aeJ} [lid]
}}}

I'm not certain that specifying an INLINE pragma in this context even makes sense, in which case perhaps a more useful warning could be produced.",jwlato
3,7543,16,ekmett@…,Constraint synonym instances,Compiler,7.6.1,7.8.1,,new,normal,2013-04-12T15:10:06-0700,"It would be great if GHC could compile:

{{{
{-# LANGUAGE ConstraintKinds #-}

type Ring = Num

instance Ring [a] where
  (+) = (++)
}}}

Currently this gives an error: `(+)` is not a visible method of class `Ring`. After removing the last line, the code compiles with warnings about missing methods.",monoidal
3,1473,16,gwern0@…,isSpace is too slow,libraries/base,6.6.1,_|_,,new,normal,2013-01-22T08:16:47-0800,"In the thread starting http://www.haskell.org/pipermail/glasgow-haskell-users/2007-May/012608.html
Neil Mitchell compares the speed is isSpace to C's functions:
{{{
C's isspace: 0.375
C's iswspace: 0.400
Char.isSpace: 0.672
}}}
The thread contains some discussions of possible solutions.",igloo
3,2180,16,svein.ove@…,"Any installed signal handler stops deadlock detection, but XCPU never happens in a deadlock",Runtime System,6.9,_|_,Baughn,new,normal,2009-07-24T10:44:02-0700,"The runtime system's deadlock detection, being a debugging feature, rightly doesn't break a deadlock if there's any chance a signal will do so later. However, if the only installed signal is XCPU - cpu time-limit exceeded - then that will almost never happen in practice; any program that does want to wait for it will be waiting quite literally years.

As such, it seems best if XCPU is left out of the signal-detection logic. The attached patch does this.",Baughn
3,7261,16,roma@…,ghci's :info and :browse break encapsulation,GHCi,7.6.1,_|_,,new,normal,2013-04-12T09:09:45-0700,"In ghci, :info shows representations of abstract data types. I consider this undesirable, since it breaks abstraction and confuses users.

Example:
{{{
Prelude> :m +Data.Unique 
Prelude Data.Unique> :i Unique 
newtype Unique = Data.Unique.Unique Integer
  	-- Defined in `Data.Unique'
}}}

I would expect it to behave in the same way as Haddock does, i.e. just show ""data Unique"".

Same about the :browse command.",Feuerbach
4,4340,16,mmitar@…,Add alignment to hsc2hs template,Compiler (FFI),6.12.3,7.6.2,,new,low,2012-09-12T04:12:30-0700,"I think [http://www.haskell.org/haskellwiki/FFICookBook#Working_with_structs commonly used]:

{{{
#let alignment t = ""%lu"", (unsigned long)offsetof(struct {char x__; t (y__); }, y__)
}}}

should be added to official hsc2hs template. What are cons to that?",mitar
4,4806,16,mmitar@…,Make error message more user friendly when module is not found because package is unusable,Compiler,7.0.1,7.6.2,,new,low,2012-09-12T04:12:33-0700,"Make error message more user friendly when module is not found because package is unusable. Currently it just reports that module is missing (the same as it even would not be installed) but then checking with `ghc-pkg find-module` shows package correctly. Chasing '-v' output around can then show you this but it would be easier that you would immediately get a helpful message.
",mitar
3,5355,15,as@…,Link plugins against existing libHSghc,Compiler,7.0.3,7.6.2,,new,normal,2012-09-12T04:12:02-0700,"This ticket split out from #3843 since it was getting too crowded

Once we can safely export all symbols from libHSghc through the executable, we want to link plugins against the loaded GHC library rather than a new copy. This has two benefits:

  1. Linking plugins will be faster
  2. We can make reinitializeGlobals into a no-op

This is currently blocked by #5292 because libHSghc exports more symbols than we can reexport on Windows. There is one suggestions in #3843 to reexport less: exclude more of GHC's dependencies from being reexported, using this snippet to get the package list:

{{{
$(foreach p,$(PACKAGES),$p-$(libraries/$p_dist-install_VERSION))
}}}

Once we have cut the number of exported symbols down enough, the patches in #3843's attachment 3843-v2.zip can be applied to fix this ticket. (There was a reported validate failure with this patch in annrun01 on x64 linux which should also be checked)",batterseapower
3,3511,15,zooko@…,port GHC to OpenBSD/sparc64 (unregisterised is fine),Compiler,6.11,_|_,,new,normal,2010-12-03T09:55:10-0800,"Folks:

I'm a developer of the Tahoe-LAFS open source project (http://allmydata.org ) and we use darcs, and there is a contributor who would like to help us support Tahoe-LAFS on OpenBSD/sparc64 (note: not OpenBSD/sparc).  It would be really nice if that contribute could use darcs to get the latest Tahoe-LAFS source code and to contribute patches.  But, GHC isn't ported to OpenBSD/sparc64.  This ticket is to request the feature of a port of GHC to OpenBSD/sparc64.  An unregisterised port would be fine!

Thanks!
",zooko
4,5316,15,conal@…,Orphan instances strike again: ghc rejects a program at first but will accept it if you repeat the same compilation command,Compiler,7.0.4,_|_,,new,low,2011-07-26T09:48:55-0700,"Consider these two modules (boiled down example from the checkers package):

{{{
{-# LANGUAGE ScopedTypeVariables, FlexibleContexts #-}

module T1

where

import Test.QuickCheck
import Text.Show.Functions ()


f :: forall m a b.  ( Arbitrary (a->b) ) => m (a,b) -> Property
f = const $ property (undefined :: (a->b) -> Bool)
}}}

{{{
module T2  where

import Control.Concurrent

g = threadDelay maxBound
}}}

I see the following interaction:

{{{
$ rm *hi *.o
$ ghc --make -c -O  T1 T2
[1 of 2] Compiling T2               ( T2.hs, T2.o )
[2 of 2] Compiling T1               ( T1.hs, T1.o )

T1.hs:12:13:
    Overlapping instances for Show (a -> b)
      arising from a use of `property'
    Matching instances:
      instance Show (a -> b) -- Defined in Text.Show.Functions
      instance Show base:System.Event.Manager.IOCallback
        -- Defined in base:System.Event.Manager
    (The choice depends on the instantiation of `a, b'
     To pick the first instance above, use -XIncoherentInstances
     when compiling the other instance declarations)
    In the second argument of `($)', namely
      `property (undefined :: (a -> b) -> Bool)'
    In the expression: const $ property (undefined :: (a -> b) -> Bool)
    In an equation for `f':
        f = const $ property (undefined :: (a -> b) -> Bool)
$ ghc --make -c -O  T1 T2
[2 of 2] Compiling T1               ( T1.hs, T1.o )
$ ghc --make -c -O  T1 T2
$ ls
T1.hi T1.hs T1.o  T2.hi T2.hs T2.o
}}}

I see this consistent behaviour in versions 7.0.{1,2,3,4} but not with 6.12.1
",jcpetruzza
5,2224,15,dons@…,-fhpc inteferes/prevents rewrite rules from firing,Code Coverage,6.8.2,7.6.2,andy@…,new,lowest,2012-09-12T04:13:56-0700,"Use case:

I'm writing tests for rewrite rules, and using HPC to determine if rules were fired (and their code exercised). HPC is quite cool here, since it lets us see which rules fired, without needing to explicitly export functions to test.

However, -fhpc seems to prevent many rules from firing (likely due to ticks getting in the way?)

For example:

{{{
import qualified  Data.ByteString.Char8 as C

main = print (C.pack ""literal"")
}}}

When compiled normally, triggers a nice rewrite rule:

{{{
$ ghc -O2 A.hs -ddump-simpl-stats A.hs -c

    1 ByteString pack/packAddress
}}}

Now with -fhpc:

{{{
2 RuleFired
    1 unpack
    1 unpack-list
}}}

What's the best way to ensure the same code is exercised with and without -fhpc here? (I'd quite like to get this working, since rewrite rules benefit from testing.)",dons
5,2991,15,andygill@…,.mix files generation broken with -fhpc and --make flags with lhs modules,Code Coverage,6.10.1,7.6.2,andy@…,new,lowest,2012-09-12T04:14:07-0700,"assume the project consisting of two files: !Main.lhs and !MyModule.hs. Main.lhs imports !MyModule via standard import. Build the project with

ghc --make -fhpc -o main Main.lhs

The generated .mix file contains relevant information and hpc markup correctly shows the coverage for !MyModule.

Now rename !MyModule.hs to !MyModule.lhs and enclose the code there in \begin{code} / \end{code}. Build again. The compilation still succeeds and the executable works fine. But !MyModule.mix now seems wrong and no hpc coverage information is available for !MyModule",ppavel
5,3073,15,ganesh@…,Avoid reconstructing dictionaries in recursive instance methods,Compiler,6.10.1,7.6.2,,new,lowest,2012-09-12T04:14:08-0700,"Ganesh writes: I have a problem in GHC 6.10 with functions in a class instance calling
other functions in the same class instance. It seems that the dictionary
is freshly constructed for this call, despite being already available.

The reason I care is that I want to memoise some expensive computations
inside the dictionary for each instance. [Obviously I also have to make
sure that the dictionary isn't constructed multiple times by external
callers, but I can make other arrangements to ensure that.]

To see the problem in action, run main from the attached code. In GHC 6.8
and before, this only executes the trace statement once. In GHC 6.10, the
trace statement executes twice, at all optimisation levels.

This seems related to #2902, but I'm a little unclear on whether it's the same problem or not.

",simonpj
5,3859,15,zooko@…,Problems with toClockTime on NetBSD,Compiler,6.12.1,7.6.2,,new,lowest,2012-09-12T04:14:14-0700,"http://bugs.darcs.net/msg8960 (part of http://bugs.darcs.net/issue1524) says:
{{{
Got it: reproducing the crash (tough on such a slow machine where rebuilding 
these things is quite the process, yay me):

<patch author='zooko@zooko.com' date='20090308025039' local_date='Making 
friendly CalendarTime {ctYear = 2009, ctMonth = March, ctDay = 8, ctHour = 2, 
ctMin = 50, ctSec = 39, ctPicosec = 0, ctWDay = Sunday, ctYDay = 0, ctTZName = 
""GMT"", ctTZ = 0, ctIsDST = False}

Plugging that into your first requested program:

import System.Time

-- this is one line
main = print . toClockTime $ CalendarTime 2009 March 8 2 50 39 0 Sunday 0 ""GMT"" 
0 False

... returns:

t: user error (Time.toClockTime: invalid input)

So..  This suggests to me there are two problems. First, the toClockTime 
function has trouble with certain input.

This fails:
-- this is one line
main = print . toClockTime $ CalendarTime 2009 March 8 2 59 59 1000 Thursday 
280 ""BST"" 3600 True

This succeeds:
-- this is one line
main = print . toClockTime $ CalendarTime 2009 March 8 3 0 0 0 Thursday 280 
""BST"" 3600 True

Weird huh?

And then clearly, the second problem appears to be the conversion of the 
datestamp in the following partial log entry:

<patch author='zooko@zooko.com' date='20090308025039' local_date='Making 
friendly CalendarTime {ctYear = 2009, ctMonth = March, ctDay = 8, ctHour = 2, 
ctMin = 50, ctSec = 39, ctPicosec = 0, ctWDay = Sunday, ctYDay = 0, ctTZName = 
""GMT"", ctTZ = 0, ctIsDST = False}

(This is with a modified darcs with the printf-equivalent in it.)

This is suspiciously near to the DST switchover. If you need a zdump of my 
current DST timings, I can provide the pre-zic entries.

Is there perhaps a DST switchover assumption in that logic?

Let me know if you'd like me to delve further. Hopefully this is enough to make 
the problem clear to you darcs folks.
}}}

This really needs to be looked at by someone with access to NetBSD (or perhaps some similar OS).
",igloo
5,2135,15,dons@…,Warn if functions are exported whose types cannot be written,Compiler,6.8.2,7.6.2,,new,lowest,2012-09-12T04:13:45-0700,"It should be possible to warn if a function is exported from a module whose type is hidden, and thus the function's type can't be written down directly by the user.

With the proliferation in type level programming in Haskell (and its use in libraries), situations
can arise where functions are exported from a module which can be used, but whose type cannote be written, but where the type is complex enough that it really is required to write it down for the code to compile. This happened recently in the takusen library.

A warning for this situation would help authors of libraries avoid this situation.

",dons
3,7849,14,oleg@…,Error on pattern matching of an existential whose context includes a type function,Compiler (Type checker),7.4.2,,,new,normal,2013-04-22T05:53:15-0700,"The following code
{{{
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE GADTs #-}

module Ex where

import Data.IORef

class SUBJ subj where
    type SUBJ_Obs subj :: *
    unsubscribe' :: subj -> SUBJ_Obs subj -> IO ()

data ASubj obs = forall subj. (SUBJ subj, SUBJ_Obs subj ~ obs) => ASubj subj
-- data ASubj obs = forall subj. (SUBJ subj) => ASubj subj (obs -> SUBJ_Obs subj)

class OBS obs where
    subscribed :: obs -> ASubj obs -> IO ()
    withdraw   :: obs -> IO ()

-- The implementation of Obs
data Obs = Obs{obs_subjects :: IORef [ASubj Obs]}

instance OBS Obs where
    subscribed obs subj = modifyIORef (obs_subjects obs) (subj:)
    withdraw obs = do
      subjs <- readIORef (obs_subjects obs)
      writeIORef (obs_subjects obs) []
      mapM_ (\ (ASubj subj) -> unsubscribe' subj obs) subjs
--    mapM_ (\ (ASubj subj cast) -> unsubscribe' subj (cast obs)) subjs

}}}
gives a rather obscure type error

{{{
    Couldn't match type `b0' with `()'
      `b0' is untouchable
           inside the constraints (SUBJ subj, SUBJ_Obs subj ~ Obs)
           bound at a pattern with constructor
                      ASubj :: forall obs subj.
                               (SUBJ subj, SUBJ_Obs subj ~ obs) =>
                               subj -> ASubj obs,
                    in a lambda abstraction
    In the pattern: ASubj subj
    In the first argument of `mapM_', namely
      `(\ (ASubj subj) -> unsubscribe' subj obs)'
    In a stmt of a 'do' block:
      mapM_ (\ (ASubj subj) -> unsubscribe' subj obs) subjs
-}
}}}
It is not even clear what b0 is: the code has no type variable named b.
Incidentally, if I use the explicit cast (as in the commented out
declaration of ASubj) and change the last line of withdraw accordingly (as shown in the commented out line), the code compiles.
It seems that what I am trying to accomplish is reasonable.

Incidentally, why GHC insists on the extension GADTs given that I already specified ExistentialQuantification? It seems when opening amn existential GADTs extension must be present. It seems ExistentialQuantification no longer has any point?",guest
3,7978,14,kazu@…,Profiling broken,Compiler,7.7,,,new,normal,2013-06-18T14:15:28-0700,"The cardinality analysis patch broke profiling. This can be seen in the nightly builds, where the profasm and profthreaded ways show many, many failures. ghc:changeset:da4ff650 is good, and ghc:changeset:62653122 is bad; the intervening few changes are not buildable.

",gmainland
3,7867,14,batterseapower,Allow template-haskell to communicate with itself between compilation units through the interface file,Template Haskell,7.6.3,,,new,normal,2013-06-17T08:48:34-0700,"I'd like to be able to have something like this in the Q monad:
{{{
  type MessageName = String -- or something better, I don't know
  writeIface :: (Quasi q, Serializable a) => MessageName -> a -> q ()
  readIfaces :: (Quasi q, Serializable a) => MessageName -> q [a]
}}}
Or instead of returning `[a]`, I'm of course fine with a `Monoid`, I just need the gathered results for every occurrance of the MessageName.

This has to be in the interface file, because I'd like this to work through compilation units, like class instances, I'd like to get every result in the readIfaces call that is ever imported from the current module (transitive closure).

Please note, that in a very hacky way this is already possible to do by abusing classes.  Namely, I create an empty class for my message type.  When I want to send a message, I create a new empty datatype named for the message and I make this an instance of the class.  Then on the receiving side I just have to reify the class and I will receive all my instance names/messages.

This came up while implementing the `HFlags` library:
http://hackage.haskell.org/package/hflags

Maybe I shouldn't be proud of this, but we currently do the hacky way explained above.  I would love to have a clean approach.",errge
3,624,14,ezyang@…,Program location for thread error messages,Compiler,None,_|_,,new,normal,2010-09-17T18:49:14-0700,"In programs with a substantial number of threads, the error messages like ""indefinitely blocked"" are not very helpful, because there is no indication as to which thread blocked.  Having the source location of the 'fork' or so, would be much more helpful.",chak
4,3924,14,beroal@…,Strictness analyser missing useful strictness,Compiler,6.12.1,7.6.2,,new,low,2012-09-12T04:12:22-0700,"Roman Beslik (beroal@ukr.net) writes: 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
}}}
",simonpj
4,5654,14,ezyang@…,Profiling semantics bug,Profiling,7.2.1,7.6.2,simonmar,new,low,2013-03-11T12:58:00-0700,"GHC doesn't quite implement the new cost-centre stack semantics correctly. e.g.

{{{
{-# NOINLINE f #-}
f :: Int -> Int
f = {-# SCC f #-} g

{-# NOINLINE g #-}
g :: Int -> Int
g x = {-# SCC g #-} x + 1

main = print (f 3)
}}}

What we want is

{{{
 CAF        Main                    106           0    0.0    0.7     0.0   21.7
  f         Main                    201           1    0.0    0.0     0.0    0.0
  main      Main                    200           1    0.0   20.9     0.0   21.0
   f        Main                    202           0    0.0    0.0     0.0    0.1
    g       Main                    203           1    0.0    0.1     0.0    0.1
}}}

but we get

{{{
 CAF        Main                    106           0    0.0    0.7     0.0   21.6
  f         Main                    201           1    0.0    0.0     0.0    0.0
  main      Main                    200           1    0.0   20.9     0.0   20.9
   g        Main                    202           1    0.0    0.0     0.0    0.0
}}}

The original flat CC profiler used to use `IND_PERM` indirections to handle this kind of thing, but we aren't doing that now.",simonmar
4,4016,14,kazu@…,Strange display behaviour in GHCi,Compiler,6.12.2,7.6.2,,new,low,2012-09-12T04:12:23-0700,"Kazu encountered another GHCi oddity.  Try "":browse Prelude"" in GHCi.  With 6.12 we get
{{{
data Integer
  = integer-gmp:GHC.Integer.Type.S# GHC.Prim.Int#
  | integer-gmp:GHC.Integer.Type.J# GHC.Prim.Int# GHC.Prim.ByteArray#
}}}
Why do we get the `integer-gmp:` prefix?  There is no ambiguity here.  (GHC 6.10 didn't do this, but that's because `Integer` was in the `base` package, whereas now `Integer` is in `integer-gmp`.)
",simonpj
5,2273,14,ezyang@…,inlining defeats seq,Compiler,6.9,7.6.2,,new,lowest,2013-02-01T12:08:29-0800,"Consider this module:
{{{
module Q (tcExtendIdEnv2) where

-- Interesting code:

tcExtendIdEnv2 :: M a
tcExtendIdEnv2 = do env <- getEnv
                    let level :: Int
                        level = thLevel (tcl_th_ctxt env)
                    level `seq` tc_extend_local_id_env level

{-# NOINLINE tc_extend_local_id_env #-}
tc_extend_local_id_env :: Int -> M a
tc_extend_local_id_env th_lvl = if read ""foo""
                                then th_lvl `seq` return undefined
                                else return undefined

thLevel :: ThStage -> Int
thLevel Comp       = 0
thLevel (Splice l) = l
thLevel (Brack l)  = l

-- Dull code:

type M a = IOEnv TcLclEnv a

data TcLclEnv = TcLclEnv { tcl_th_ctxt :: !ThStage }

data ThStage = Comp | Splice Int | Brack  Int

getEnv :: IOEnv env env
getEnv = IOEnv (\ env -> return env)

newtype IOEnv env a = IOEnv { unIOEnv :: env -> IO a }

instance Monad (IOEnv m) where
    IOEnv m >>= f = IOEnv (\ env -> do r <- m env
                                       unIOEnv (f r) env )
    return a = IOEnv (\ _ -> return a)
    fail = error
}}}
Compiling with
{{{
ghc -O -ddump-simpl -ddump-stg -c Q.hs
}}}
we get, in the STG,
{{{
Q.$wa =
    \r srt:(0,*bitmap*) [ww_sDx w_sDO]
        case
            case ww_sDx of wild_sEs {
              Q.Comp -> Q.lvl;
              Q.Splice l_sDA -> l_sDA;
              Q.Brack l_sDC -> l_sDC;
            }
        of
        tpl_sEt
        { GHC.Base.I# ipv_sEu ->
              let { sat_sDN = NO_CCS Q.TcLclEnv! [ww_sDx]; } in
              let {
                sat_sDL =
                    \u []
                        case ww_sDx of wild_sEv {
                          Q.Comp -> Q.lvl;
                          Q.Splice l_sDH -> l_sDH;
                          Q.Brack l_sDJ -> l_sDJ;
                        };
              } in  Q.tc_extend_local_id_env sat_sDL sat_sDN w_sDO;
        };
}}}
GHC seems to have inlined `level`, forced it (due to the seq), but passed along a second, inlined, unevaluated copy to `tc_extend_local_id_env`. So the whole environment is retained, defeating the purpose of the seq!

If I mark `level` as `NOINLINE` then the STG looks like this:
{{{
Q.a5 =
    \r srt:(0,*bitmap*) [env_sD1 eta_sDh]
        case env_sD1 of tpl_sDg {
          Q.TcLclEnv ipv_sD5 ->
              case
                  case ipv_sD5 of wild_sDN {
                    Q.Comp -> Q.lvl;
                    Q.Splice l_sD8 -> l_sD8;
                    Q.Brack l_sDa -> l_sDa;
                  }
              of
              level_sDc
              { __DEFAULT ->
                    case level_sDc of tpl1_sDf {
                      GHC.Base.I# ipv1_sDO -> Q.tc_extend_local_id_env tpl1_sDf tpl_sDg eta_sDh;
                    };
              };
        };
}}}
which fixes the env-retained problem, although I don't understand why two cases are done.

It would be nice not to have to resort to this level of trickery, though!
",igloo
5,2988,13,baterseapower,Improve float-in,Compiler,6.10.1,7.6.2,,new,lowest,2012-09-12T04:14:06-0700,"At the moment we can get a cascade of simplifier iterations like this:
{{{
let x1 = blah
    x2 = x1 : []
    x3 = 1 : x2
    x4 = 2 : x3
in case blah of
  True -> f x4
  False -> g x4
}}}
Then `x4` satisfies the conditions for `postInlineUnconditionally` (not top-level, used once in each case branch, not inside lambda).  So it's inlined.  In the next iteration of the simplifier, `x3` satisfies the conditions, and so on.

It might be better for `postUnconditionally` to require an interesting context.  But then this case doesn't work so well:
{{{
   let x = blah in case foo of { A -> ..x..; B -> ..x..; C -> ..no x.. }
}}}
If C is the hot branch, it's a good idea to push `x` into the A,B branches. 

But perhaps this question is one that `FloatIn` should deal with, not `postInlineUnconditionally`.  Indeed `FloatIn` has the following comment:
{{{
		-- For case expressions we duplicate the binding if it is
		-- reasonably small, and if it is not used in all the RHSs
		-- This is good for situations like
		--	let x = I# y in
		--	case e of
		--	  C -> error x
		-- 	  D -> error x
		--	  E -> ...not mentioning x...
}}}
So this ticket is just to record the idea:
 * Make `postInlineUnconditionally` check for interesting context
...and check on performance changes, and whether `FloatIn` is doing the Right Thing.

Simon
",simonpj
3,932,12,samb simonpj,Improve inlining,Compiler,6.4.2,_|_,simonpj,new,normal,2008-09-30T08:51:08-0700,"Currently the contruct
{{{
  case (x# ># 0#) of ...
}}}
attracts no argument discount for x#, which is silly.

The comment in CoreUnfold says:
{{{
	  PrimOpId op  -> primOpSize op (valArgCount args)
			  -- foldr addSize (primOpSize op) (map arg_discount args)
			  -- At one time I tried giving an arg-discount if a primop 
			  -- is applied to one of the function's arguments, but it's
			  -- not good.  At the moment, any unlifted-type arg gets a
			  -- 'True' for 'yes I'm evald', so we collect the discount even
			  -- if we know nothing about it.  And just having it in a primop
			  -- doesn't help at all if we don't know something more.
}}}
But the right thing to do seems to be to fix interestingArg in SimplUtils so that it only thinks a primitive-typed thing is interesting if it knows its value (or some structure).

Here's the program that triggered this thought:
{{{
import GHC.Word
import GHC.Base
import GHC.Prim

a `shiftRLT` b | b >=# 32# = int2Word# 0#
                | otherwise = a `uncheckedShiftRL#` b

(W32# x#) `shift` (I# i#) =
{- we do an actual case analysis on i# to try to give us a discount -}
   case i# of
    {- For some bizzare reason removing the `shiftRLT` 0# makes the
       inlining fail again -}
    0# -> W32# (x# `shiftRLT` 0#)
    _ -> 
	 if i# >=# 0# then W32# (narrow32Word# (x# `shiftL#` i#))
         else W32# (x# `shiftRLT` negateInt# i#)

x `shiftR` y = x `shift` (-y)

shift7 x = x `shiftR` 7
}}}
roconnor@theorem.ca initiated the thread",simonpj
3,5687,11,hvr@…,Friendly Interface for auto-completion of GHCi,GHCi,7.2.1,7.6.2,,new,normal,2013-06-09T03:06:26-0700,"Now the GHCi can do TAB completion when running in term.

But in Emacs/Inf-Haskell mode, TAB completion doesn't work.
It should be great that if GHCi support the command like ""complete"" in GDB. 

If GHCi supports this, it's easy to implement TAB completion in Emacs/Inf-Haskell mode.",linsumang
3,6040,10,fox@…,Adding a type signature changes heap allocation into stack allocation without changing the actual type,Compiler,7.4.1,7.8.1,simonpj,new,normal,2012-12-06T05:59:53-0800,"According to Milan Straka, changing

{{{
insert :: Ord k => k -> a -> Map k a -> Map k a
insert = go
  where
    STRICT_1_OF_3(go)
    go kx x Tip = singleton kx x
    go kx x (Bin sz ky y l r) = ...
}}}

to

{{{
insert :: Ord k => k -> a -> Map k a -> Map k a
insert = go
  where
    go :: Ord k => k -> a -> Map k a -> Map k a
    STRICT_1_OF_3(go)
    go kx x Tip = singleton kx x
    go kx x (Bin sz ky y l r) = ...
}}}

changes how GHC allocates the argument, from heap to stack. Here's the relevant commit: https://github.com/haskell/containers/commit/32d84ba5eb82f34dbb8a8fabf07077d848cdb408

It includes this comment:
{{{
-- [Note: Type of local 'go' function]
-- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-- If the local 'go' function uses an Ord class, it must be given a type
-- which mentions this Ord class. Otherwise it is not passed as an argument and
-- it is instead heap-allocated at the entry of the outer method.
}}}

I find this quite alarming. The type of `k` above is already Ord k, so the extra type signature shouldn't make a difference in my opinion.
",tibbe
3,6056,10,fox@…,INLINABLE pragma prevents worker-wrapper to happen.,Compiler,7.4.1,7.8.1,simonpj,new,normal,2012-10-09T07:30:33-0700,"When working on containers I found out that a method returning a pair marked as INLINABLE does not go through a worker/wrapper transformation to get a worker that would return unboxed pair.

For example:

{{{
module Test where

smallerAndRest :: Ord a => a -> [a] -> (Maybe a, [a])
smallerAndRest x [] = (Nothing, [])
smallerAndRest x (y:ys) | y < x = (Just y, ys)
                        | otherwise = smallerAndRest x ys

{-# INLINABLE smallerAndRest #-}
}}}

With the `INLINABLE` pragma, `-ddump-prep` prints
{{{
==================== CorePrep ====================
Result size = 42

lvl_rkg :: forall a_ajz. (Data.Maybe.Maybe a_ajz, [a_ajz])
[GblId, Caf=NoCafRefs, Str=DmdType m, Unf=OtherCon []]
lvl_rkg =
  \ (@ a_ajz) -> (Data.Maybe.Nothing @ a_ajz, GHC.Types.[] @ a_ajz)

Rec {
Test.smallerAndRest [InlPrag=INLINABLE[ALWAYS], Occ=LoopBreaker]
  :: forall a_a9I.
     GHC.Classes.Ord a_a9I =>
     a_a9I -> [a_a9I] -> (Data.Maybe.Maybe a_a9I, [a_a9I])
[GblId, Arity=3, Caf=NoCafRefs, Str=DmdType LLSm, Unf=OtherCon []]
Test.smallerAndRest =
  \ (@ a_ajz)
    ($dOrd_sko :: GHC.Classes.Ord a_ajz)
    (x_skq :: a_ajz)
    (ds_skk :: [a_ajz]) ->
    case ds_skk of _ {
      [] -> lvl_rkg @ a_ajz;
      : y_skp ys_sks ->
        case GHC.Classes.< @ a_ajz $dOrd_sko y_skp x_skq of _ {
          GHC.Types.False ->
            Test.smallerAndRest @ a_ajz $dOrd_sko x_skq ys_sks;
          GHC.Types.True ->
            let {
              sat_skw :: Data.Maybe.Maybe a_ajz
              [LclId]
              sat_skw = Data.Maybe.Just @ a_ajz y_skp } in
            (sat_skw, ys_sks)
        }
    }
end Rec }
}}}

but without the `INLINABLE` pragma, we get
{{{
==================== CorePrep ====================
Result size = 57

Rec {
Test.$wsmallerAndRest [Occ=LoopBreaker]
  :: forall a_a9I.
     GHC.Classes.Ord a_a9I =>
     a_a9I -> [a_a9I] -> (# Data.Maybe.Maybe a_a9I, [a_a9I] #)
[GblId, Arity=3, Caf=NoCafRefs, Str=DmdType LLS, Unf=OtherCon []]
Test.$wsmallerAndRest =
  \ (@ a_a9I)
    (w_skC :: GHC.Classes.Ord a_a9I)
    (w1_skE :: a_a9I)
    (w2_sky :: [a_a9I]) ->
    case w2_sky of _ {
      [] -> (# Data.Maybe.Nothing @ a_a9I, GHC.Types.[] @ a_a9I #);
      : y_skD ys_skG ->
        case GHC.Classes.< @ a_a9I w_skC y_skD w1_skE of _ {
          GHC.Types.False ->
            Test.$wsmallerAndRest @ a_a9I w_skC w1_skE ys_skG;
          GHC.Types.True ->
            let {
              sat_skV :: Data.Maybe.Maybe a_a9I
              [LclId]
              sat_skV = Data.Maybe.Just @ a_a9I y_skD } in
            (# sat_skV, ys_skG #)
        }
    }
end Rec }

Test.smallerAndRest [InlPrag=INLINE[0]]
  :: forall a_a9I.
     GHC.Classes.Ord a_a9I =>
     a_a9I -> [a_a9I] -> (Data.Maybe.Maybe a_a9I, [a_a9I])
[GblId, Arity=3, Caf=NoCafRefs, Str=DmdType LLSm, Unf=OtherCon []]
Test.smallerAndRest =
  \ (@ a_a9I)
    (w_skL :: GHC.Classes.Ord a_a9I)
    (w1_skM :: a_a9I)
    (w2_skN :: [a_a9I]) ->
    case Test.$wsmallerAndRest @ a_a9I w_skL w1_skM w2_skN
    of _ { (# ww1_skR, ww2_skS #) ->
    (ww1_skR, ww2_skS)
    }
}}}
Here the worker-wrapper creates a variant, which returns unboxed pair.


I assume that there is no simple solution to this, because the worker/wrapper changes the INLINABLE on `smallerAndRest` to INLINE. The INLINABLE could be added to `$wsmallerAndRest`, but then #5928 causes the specialization to fail.

Maybe at least both `smallerAndRest` and `$wsmallerAndRest` could be marked `INLINABLE`? Then it is not sure that `smallerAndRest` gets INLINED and `$wsmallerAndRest` exposed, but it is not worse than current situation.",milan
3,4934,10,"tibbe, bos",threadWaitRead works incorrectly on nonthreaded RTS,Runtime System,7.0.1,_|_,,new,normal,2011-06-01T07:37:55-0700,"I found out it in xmobar on ghc-7.0.1.
When I ran it I got the following message:
{{{
xmobar: file descriptor 8954336 out of range for select (0--1024).
Recompile with -threaded to work around this.
}}}
'''-threaded''' option works, but the message is absolutely misleading.

I've decided to track where so large descriptor could come,
but there was no such place.

All xmobar does is:
{{{
    do x11connection_fd <- connectionNumber d
       threadWaitRead (Fd fd) -- here we die
}}}

'''x11connection_fd''' has value '''3''' at the time of call.
This value comes from '''libX11''' (via FFI, so I suspect it's a problem).

Another example (might be unrelated):
{{{
-- a.hs 
import Control.Concurrent

-- 12 is picked at random as guaranteed to be invalid FD
main = threadWaitRead 12 >> print ""yet input!""
}}}

Building:
{{{
$ ghc --make -fforce-recomp a.hs -o a
[1 of 1] Compiling Main             ( a.hs, a.o )
Linking a ...

$ ghc --make -fforce-recomp a.hs -threaded -o a.threaded
[1 of 1] Compiling Main             ( a.hs, a.o )
Linking a.threaded ...
}}}

Running:
{{{
$ ./a.threaded 
a.threaded: epollControl: invalid argument (Bad file descriptor)
}}}

Looks good.

And nonthreaded:
{{{
$ ./a
""yet input!""
}}}

According to strace there was an error but it was not reported.
{{{
sf tmp # strace -etrace='select,write' ./a >/dev/null
select(13, [12], [], NULL, {134, 217727}) = -1 EBADF (Bad file descriptor) # this one

select(2, [], [1], NULL, {0, 0})        = 1 (out [1], left {0, 0})
write(1, ""\""yet input!\""\n"", 13)        = 13
}}}

Side note: Haskeline seems to workaround this problem on it's own way.

'''libraries/haskeline/System/Console/Haskeline/Backend/Posix.hsc'''
{{{
-- Different versions of ghc work better using different functions.
blockUntilInput :: Handle -> IO ()
#if __GLASGOW_HASKELL__ >= 611
-- threadWaitRead doesn't work with the new ghc IO library,
-- because it keeps a buffer even when NoBuffering is set.
blockUntilInput h = hWaitForInput h (-1) >> return ()
#else
-- hWaitForInput doesn't work with -threaded on ghc < 6.10
-- (#2363 in ghc's trac)
blockUntilInput h = unsafeHandleToFd h >>= threadWaitRead
#endif
}}}",slyfox
3,7952,8,simonmar,Can cost-centre annotations be included in -ddump-simpl?,Compiler,7.6.3,,,new,normal,2013-06-17T12:00:47-0700,"I'm trying to diagnose an allocation problem.  I'm using both explicit cost-centre annotations and {{{-fprof -fprof-auto}}}.  I'm running with {{{+RTS -pa -hc}}}.  To understand what I'm seeing in the profiles, I'm looking at the output from the {{{ghc-core}}} tool, which I think include {{{-ddump-simpl}}}. 

If I understand the semantics correctly, allocations are indicated by {{{let}}} bindings in the Core.  It would be ''hugely'' helpful if each of these {{{let}}} bindings were annotated with the cost centre to which the allocation is charged.  A great aid to debugging!

If we can help with this idea, please let me know.",nr
5,1612,8,eivuokko,GHC_PACKAGE_PATH and $topdir bug,Package system,6.6.1,7.6.2,,new,lowest,2013-01-26T14:21:44-0800,"In ghc-pkg $topdir is replaced according to path to package that is considered global - the last on in GHC_PACKAGE_PATH (if it doesn't contain trailing ';')

Following shows how (head, 1.1.7) Cabal's haddock-command gets broken.

{{{
C:\Users\eivuokko>copy con temp.conf
[]
^Z
        1 file(s) copied.

C:\Users\eivuokko>set GHC_PACKAGE_PATH=c:\tools\ghc\ghc-6.6.1\package.conf;c:\Us
ers\eivuokko\temp.conf

C:\Users\eivuokko>ghc-pkg field base haddock-interfaces
haddock-interfaces: c:\Users\eivuokko\html\libraries\base\base.haddock

C:\Users\eivuokko>set GHC_PACKAGE_PATH=

C:\Users\eivuokko>ghc-pkg field base haddock-interfaces
haddock-interfaces: C:/tools/ghc/ghc-6.6.1\html\libraries\base\base.haddock

C:\Users\eivuokko>
}}}",eivuokko
3,7109,7,nfrisby,"Inlining depends on datatype size, even with INLINE pragmas",Compiler,7.5,7.8.1,simonpj,new,normal,2012-10-14T11:23:15-0700,"Consider the following code:
{{{
data Logic = T | F
           | Not Logic

instance GEq Logic

testEqLogic = geq (Not T) (Not F)
}}}

With a proper definitions of generic equality `geq` in class `GEq`, and an `instance Generic Logic`, we get the following core code with -O1:
{{{
Rec {
Bug.$fGEqLogic_$cgeq [Occ=LoopBreaker]
  :: Bug.Logic -> Bug.Logic -> GHC.Types.Bool
[GblId, Arity=2, Caf=NoCafRefs, Str=DmdType SS]
Bug.$fGEqLogic_$cgeq =
  \ (x_ap1 :: Bug.Logic) (y_ap2 :: Bug.Logic) ->
    case x_ap1 of _ {
      Bug.T ->
        case y_ap2 of _ {
          Bug.T -> GHC.Types.True;
          Bug.F -> GHC.Types.False;
          Bug.Not g1_aBc_ayJ -> GHC.Types.False
        };
      Bug.F ->
        case y_ap2 of _ {
          Bug.T -> GHC.Types.False;
          Bug.F -> GHC.Types.True;
          Bug.Not g1_aBc_ayJ -> GHC.Types.False
        };
      Bug.Not g1_aBc_ayJ ->
        case y_ap2 of _ {
          __DEFAULT -> GHC.Types.False;
          Bug.Not g1_aBc1_XAu -> Bug.$fGEqLogic_$cgeq g1_aBc_ayJ g1_aBc1_XAu
        }
    }
end Rec }
}}}

Nice and simple, looking just like what we would expect for an equality function for datatype `Logic`.

Now we add one more constructor to datatype `Logic` (and adapt the `Generic` instance accordingly):
{{{
data Logic = T | F
           | Not Logic 
           | And Logic Logic
}}}

GHC (HEAD) now generates 3000 lines of core code for the `Bug.$fGEqLogic_$cgeq` function, instead of something only slightly longer than above.

Why is this? The second version of our `Logic` datatype is as easy to optimise as the first version; only the terms involved will be slightly longer. Attached file `Bug2.hs` is the input which gives the correct behaviour, while `Bug3.hs` is the input with one added constructor. (You might wonder if it has to do with the fact that the added constructor has more than one argument, but this is not the source of the problem.) Both files have `INLINE` pragmas pretty much everywhere (in fact, we're not `deriving Generic` so that we can put `INLINE` pragmas on `to` and `from`).",dreixel
3,7114,7,nfrisby,Cannot recover (good) inlining behaviour from 7.0.2 in 7.4.1,Compiler,7.4.1,7.8.1,,new,normal,2012-10-20T13:45:49-0700,"(I'm sorry that this test case is so large.)

The attached module `Code3.hs` is a highly simplified version of a generic implementation of enumeration, followed by its instantiation to a datatype of lists of integers. The goal is to drive the simplifier to fully specialise the generic version to an optimised version for lists, without any reference to the generic representation constructors.

With GHC 7.0.2, the (interesting part of the) attached module compiles to the following core code (my renaming):
{{{
enumNil :: [Code2.List]
[GblId, Caf=NoCafRefs]
enumNil =
  GHC.Types.: @ Code2.List Code2.Nil (GHC.Types.[] @ Code2.List)

Rec {
lvl1_roO :: GHC.Types.Int -> [Code2.List]
[GblId, Arity=1]
lvl1_roO =
  \ (x_XnO :: GHC.Types.Int) ->
    GHC.Base.map
      @ Code2.List
      @ Code2.List
      (\ (x1_XnN :: Code2.List) -> Code2.Cons x_XnO x1_XnN)
      enumList

lvl2_roR :: [[Code2.List]]
[GblId]
lvl2_roR =
  GHC.Base.map
    @ GHC.Types.Int @ [Code2.List] lvl1_roO enumInt

enumCons :: [Code2.List]
[GblId]
enumCons = Code2.diag @ Code2.List lvl2_roR

enumList [Occ=LoopBreaker] :: [Code2.List]
[GblId, Str=DmdType]
enumList = Code2.||| @ Code2.List enumNil enumCons
end Rec }
}}}

This is exactly what is intended: no more generic representation stuff. GHC 7.4.1, however, doesn't quite achieve this, instead leaving us with the following:
{{{
enumNil :: [Code2.List]
[GblId, Caf=NoCafRefs]
enumNil =
  GHC.Types.: @ Code2.List Code2.Nil (GHC.Types.[] @ Code2.List)

Rec {
a_rme :: [Code2.K1 Code2.List]
[GblId, Str=DmdType]
a_rme =
  GHC.Base.map
    @ Code2.List
    @ (Code2.K1 Code2.List)
    (Code2.K1 @ Code2.List)
    enumList

lvl1_rmf :: GHC.Types.Int -> [Code2.List]
[GblId, Arity=1]
lvl1_rmf =
  \ (x_Xmk :: GHC.Types.Int) ->
    GHC.Base.map
      @ (Code2.K1 Code2.List)
      @ Code2.List
      (\ (x1_Xn9 :: Code2.K1 Code2.List) ->
         case x1_Xn9 of _ { Code2.K1 b_aaM -> Code2.Cons x_Xmk b_aaM })
      a_rme

lvl2_rmg :: [[Code2.List]]
[GblId]
lvl2_rmg =
  GHC.Base.map
    @ GHC.Types.Int @ [Code2.List] lvl1_rmf enumInt

enumCons :: [Code2.List]
[GblId]
enumCons = Code2.diag @ Code2.List lvl2_rmg

enumList [Occ=LoopBreaker] :: [Code2.List]
[GblId, Str=DmdType]
enumList = Code2.||| @ Code2.List enumNil enumCons
end Rec }
}}}

The strange part is the interaction between the `lvl1_rmf` and `a_rme` functions: basically `a_rme` maps `K1` over a list, and `lvl1_rmf` maps a function that takes this `K1` away.

I have no idea why 7.4.1 leaves this residue around. I have played with different inline pragmas and rewrite rules, but so far have been unable to convince GHC 7.4.1 to just do what 7.0.2 did. Turning `K1` into a `newtype` doesn't help (we're left with a newtype coercion instead).",dreixel
3,7782,7,nfrisby,flag to run the demand analysis a second time,Compiler,7.7,7.8.1,nfrisby,new,normal,2013-04-13T06:36:21-0700,"There are some tickets documenting runtime bugs that can be cleaned up by running the demand analyzer (followed by a simplifier run) a second time at the end of the pipeline: #4941, #5302, #6087. #6070 ? Others?

Here's the effects on nofib. Run time didn't seem to change as drastically.  The ""X/Y"" column headers mean ""library-flags/test-flags"" given to GHC when compiling the respective bit.

{{{
Allocations

-------------------------------------------------------------------------------
        Program                O2/O2     late-dmd+O2/O2    late-dmd+O2/late-dmd+O2
-------------------------------------------------------------------------------
   cryptarithm2             25078168           +0.0%           +8.0%
       nucleic2             98331744           +0.0%           +3.2%

       cichelli             80310632           +0.0%          -22.9%
          fasta            401159024           -9.1%           -9.1%
         fulsom            321427240           +0.0%           -2.6%
   k-nucleotide           4125102928           -0.0%           -4.8%
        knights              2037984           +0.0%           -3.7%
        mandel2              1041840           +0.0%          -21.4%
        parstof              3103208           +0.0%           -1.4%
reverse-complem            155188304          -12.8%          -12.8%
         simple            226412800           -0.0%           -1.0%
}}}
All other changes less than 1% allocation.
Note that it improves a couple tests significantly just via changes in the base libraries.

For cryptarithm2, (cf remarks in #4941)
 * 4% increase allocation is due to reboxing
 * 4% is due to dead closures, because the fix in #4962 isn't working for some reason.

For nucleic2, in var_most_distant_atom, an let-bound function is inlined after w/w, and hence grows numerous closures by a significant amount. I'm not sure where to lay the blame for this. Note however, that just making nucleic2's data types use strict !Float fields changes its allocation -72.4%, so maybe this ""bad practice"" corner case is a small issue.

The main remaining task beyond the attached patch is to repair the treatment of wrapper's strictness signatures in .hi files. Because the second demand analysis might change a these signatures, the current compaction mechanism that .hi uses results in ill-formed Core. For the attached patch, I've just disabled that .hi compaction mechanism, but this just needlessly bloats .hi files.",nfrisby
3,2255,7,nfrisby,Improve SpecConstr for free variables,Compiler,6.8.2,_|_,,new,normal,2013-03-26T09:23:29-0700,"This ticket records a suggestion for improving `SpecConstr`, so we don't lose it. The original `SpecConstr` transformation is described in ""[http://research.microsoft.com/%7Esimonpj/papers/spec-constr Call pattern specialisation for Haskell]"".  Consider this program
{{{
   f x = let g y = ...case x of { z:zs -> e1; [] -> e2 } ...
          in
          ...case x of
                z:zs -> if ... then g 3 else g 4
                []   -> ...
}}}
Here 'x' is free in 'g', but x's value is known at g's call sites.  It's not enough just to know ""x is a cons"" inside g; we must also have access to z,zs.  So perhaps the thing to do is to imagine lambda-lifting 'g' to become 'gl' thus:
{{{
  gl x y = ...case x of { z:zs -> e1; [] -> e2 } ...

  f x = ...case x of
                z:zs -> if ... then gl x 3 else gl x 4
                []   -> ...
}}}
Now the `SpecConstr` transformation will apply nicely.  And it's arguably a bad shortcoming that currently the mere act of lambda lifting can affect how effective `SpecConstr` is.

Of course, we only want to lambda-lift wrt the parameters that'll be specialised, so this transformation probably wants to be done at the same time as the rest of `SpecConstr`. I don't have much idea of how hard that'd be, but it's a nice idea.
",simonpj
2,2725,6,dterei,Remove Hack in compiler/nativeGen/MachCodeGen.hs,Compiler (NCG),6.11,7.8.1,clemens,new,high,2012-12-06T09:18:03-0800,"Remove the hack around Line 3914 labeled with:
{{{
    -- HACK: On x86_64 binutils<2.17 is only able to generate PC32
    -- relocations, hence we only get 32-bit offsets in the jump
    -- table. As these offsets are always negative we need to properly
    -- sign extend them to 64-bit. This hack should be removed in
    -- conjunction with the hack in PprMach.hs/pprDataItem once
    -- binutils 2.17 is standard.
}}}
This bug is intended for house keeping.",clemens
3,7874,6,dterei,segfault 11 on mac os x when building compiler for ghc 7.7.20130430,Compiler,7.7,,,new,normal,2013-05-30T11:09:20-0700,"I'm trying to build ghc head from the repo head as of today,
and i'm getting the following error in the stage 2 build 
{{{
carter repoScratcher/ghc ‹master› » make
===--- building phase 0
make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds
make[1]: Nothing to be done for `phase_0_builds'.
===--- building phase 1
make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds
make[1]: Nothing to be done for `phase_1_builds'.
===--- building final phase
make -r --no-print-directory -f ghc.mk phase=final all
""inplace/bin/ghc-stage2"" -hisuf hi -osuf  o -hcsuf hc -static  -H64m -O0 -fllvm    -package-name old-time-1.1.0.1 -hide-all-packages -i -ilibraries/old-time/. -ilibraries/old-time/dist-install/build -ilibraries/old-time/dist-install/build/autogen -Ilibraries/old-time/dist-install/build -Ilibraries/old-time/dist-install/build/autogen -Ilibraries/old-time/include    -optP-include -optPlibraries/old-time/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package old-locale-1.0.0.5 -XHaskell98 -XCPP -XForeignFunctionInterface -O -fllvm  -no-user-package-db -rtsopts      -odir libraries/old-time/dist-install/build -hidir libraries/old-time/dist-install/build -stubdir libraries/old-time/dist-install/build  -dynamic-too -c libraries/old-time/dist-install/build/System/Time.hs -o libraries/old-time/dist-install/build/System/Time.o -dyno libraries/old-time/dist-install/build/System/Time.dyn_o
make[1]: *** [libraries/old-time/dist-install/build/System/Time.o] Segmentation fault: 11
}}}
",carter
3,5619,6,dterei,Shorter qualified import statements,Compiler,7.2.1,7.6.2,,new,normal,2012-09-12T04:12:06-0700,"I would like to be able to write imports like
{{{
import qualified Data.Vector as V (Vector, fromList)
import Data.Vector ((!), (//))
}}}
as a single statement, like
{{{
import qualified Data.Vector ((!), (//)) as V (Vector, fromList)
}}}
Which seems to be compatible with the current import statement.",YvesPares
3,3379,6,dterei,GHC should use the standard binary package,Compiler,6.10.4,7.6.2,,new,normal,2012-09-12T04:11:58-0700,"GHC should use the standard binary package, rather than reimplementing its functionality itself. If the current binary package is slower than GHC's Binary, then we should fix that.

There's some discussion about this in #3041.
",igloo
3,3081,6,ganesh,Double output after Ctrl+C on Windows,Runtime System,6.10.1,_|_,,new,normal,2011-03-16T04:00:33-0700,"{{{
C:\Temp>type Test.hs
import Control.Exception
import System.Cmd
main = system ""sleep 1m"" `finally` putStrLn ""goodbye""

C:\Temp>ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.1

C:\Temp>ghc --make Test.hs
[1 of 1] Compiling Main             ( Test.hs, Test.o )
Linking Test.exe ...

C:\Temp>test.exe
^Cgoodbye
goodbye
C:\Temp>
}}}

The {{{^C}}} is the consoles way of saying that Ctrl+C was pressed - i.e. I ran the program and hit Ctrl+C while the sleep was still ongoing. I can replicate this issue from the DOS prompt and from the Cygwin prompt. It does not occur from GHCi.",NeilMitchell
4,3704,6,dterei,Using -shared without -dynamic should be rejected on linux,Compiler,,7.6.2,,new,low,2012-09-12T04:12:19-0700,"When trying to link with ghc -shared

{{{
$ ghc -v -fPIC -shared -o TestF.so TestF.hs
}}}

it adds a bunch of arguments of the form -lHSbase-4.2.0.0 to the linker command line

{{{
*** Linker:
/usr/bin/gcc -v -o TestF.so TestF.o -shared -Wl,-Bsymbolic -Wl,-soname,TestF.so
 -L/usr/lib/ghc-6.12.0.20091126/base-4.2.0.0 -L/usr/lib/ghc-6.12.0.20091126/integer-gmp-0.2.0.0
 -L/usr/lib/ghc-6.12.0.20091126/ghc-prim-0.2.0.0 -L/usr/lib/ghc-6.12.0.20091126 -lHSbase-4.2.0.0
 -lHSinteger-gmp-0.2.0.0 -lgmp -lHSghc-prim-0.2.0.0 -lHSffi
}}}

Unfortunately:

{{{
/usr/lib/ghc-6.12.0.20091126/base-4.2.0.0/libHSbase-4.2.0.0-ghc6.12.0.20091126.so
/usr/lib/ghc-6.12.0.20091126/base-4.2.0.0/libHSbase-4.2.0.0.a
/usr/lib/ghc-6.12.0.20091126/base-4.2.0.0/libHSbase-4.2.0.0_p.a
}}}

The name of the .so has been mangled to include the compiler version - presumably for ABI reasons. Obviously the bug is that name on the linker command line has not been suitably mangled to match, so the linker goes ahead and tries to use the .a library, which doesn't work at all.

{{{
/usr/bin/ld: /usr/lib/ghc-6.12.0.20091126/base-4.2.0.0/libHSbase-4.2.0.0.a(Base__76.o): 
relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile 
with -fPIC
}}}

Tested on linux/amd64, with HEAD and stable snapshot. It may work on linux/i386 due to compatibility hacks in glibc, I haven't checked; it shouldn't work on anything else.",asuffield
4,3767,6,dterei,SpecConstr for join points,Compiler,6.12.1,7.6.2,,new,low,2012-09-12T04:12:20-0700,"The attached file `Spec.hs` has a case (from Roman's fusion code) where `SpecConstr` is not doing the right thing.  Let's look at one of the mutually recursive loops that `SpecConstr` generates for foo:
{{{
lvl_rzY :: GHC.Types.Int
lvl_rzY = GHC.Types.I# 2147483647

lvl1_rA0 :: Data.Either.Either GHC.Types.Int GHC.Types.Int
lvl1_rA0 = Data.Either.Left @ GHC.Types.Int @ GHC.Types.Int lvl_rzY

$s$wgo_szT :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int#
$s$wgo_szT =
  \ (sc_sz6 :: GHC.Prim.Int#) (sc1_sz7 :: GHC.Prim.Int#) ->
    let {
      $w$j_syG
        :: GHC.Prim.Int#
           -> Data.Either.Either GHC.Types.Int GHC.Types.Int
           -> GHC.Prim.Int#
      [LclId, Arity=2, Str=DmdType LS]
      $w$j_syG =
        \ (ww_sy6 :: GHC.Prim.Int#)
          (w2_sy8 :: Data.Either.Either GHC.Types.Int GHC.Types.Int) ->
          case GHC.Prim.<=# ww_sy6 0 of _ {
            GHC.Bool.False -> $wgo_syE (GHC.Prim.+# sc_sz6 ww_sy6) w2_sy8;
            GHC.Bool.True -> $wgo_syE sc_sz6 w2_sy8
          } } in
    case GHC.Prim.># sc1_sz7 0 of _ {
      GHC.Bool.False -> $s$wgo1_szS sc_sz6 ipv_swo;
      GHC.Bool.True ->
        case sc1_sz7 of wild1_awb {
          __DEFAULT ->
            case GHC.Prim.remInt# wild1_awb 2 of _ {
              __DEFAULT -> $s$wgo_szT sc_sz6 (GHC.Prim.-# wild1_awb 1);
              0 ->
                case w1_syr of _ { GHC.Types.I# ww_sy6 ->
                $w$j_syG
                  ww_sy6
                  (Data.Either.Left
                     @ GHC.Types.Int
                     @ GHC.Types.Int
                     (GHC.Types.I# (GHC.Prim.-# wild1_awb 1)))
                }
            };
          (-2147483648) ->
            case w1_syr of _ { GHC.Types.I# ww_sy6 ->
            $w$j_syG ww_sy6 lvl1_rA0
            }
        }
    };
}}}
Note that the join point has an argument of type `(Either Int Int)` but it is always called with `(Left (I# <n>))`. This means that the recursive call in the join point is always of the form `($wgo_syE <m> (Left (I# <n>)))` and we have a specialisation for that.  However the join point itself doesn't scrutinse its argument, and that means that GHC ignores the potential specialisation.  

Simon 

",simonpj
4,3712,6,dterei,Implement -dynamic-lib option,Compiler,6.12.1 RC1,7.6.2,,new,low,2012-09-12T04:12:19-0700,"The proposal is to add a new option `-dynamic-lib`, to be used when building a shared library.  It would be both a compile-time and a link-time option, and could be used with `--make` to build a complete shared library in one go.  It would avoid the pitfalls caused by there being combinations of `-dynamic` and `-fPIC` don't do what the user expects.

Specifically, `-dynanmic-lib` would imply `-dyanamic`, `-fPIC` where necessary, and `-shared` when linking.

See #3705 for more discussion.
",simonmar
4,5140,6,dterei,Fix LLVM backend for PowerPC,Compiler (LLVM),7.1,7.6.2,erikd,new,low,2012-12-06T09:32:47-0800,"LLVM backend does not work for PowerPC.

From bug #5131 davidt says the order of business is:
{{{
   a) Get unregistered working.
   b) Get registered without TABLES_NEXT_TO_CODE.
   c) Get TABLES_NEXT_TO_CODE working.
   d) Ask David where to go from there.
}}}

Actually there is now a guide of sorts [wiki:Commentary/Compiler/Backends/LLVM/GHC_LLVMPorting here].",erikd
4,1176,6,dterei,Infinite loop when printing error message,Compiler,6.6,_|_,thorkilnaur,new,low,2013-01-21T08:41:45-0800,"I am trying to compile a file that has a known compile error.  Ghc gets into an infinite loop trying to output the error message.

Here's the session (captured using EMACS shell):

{{{
pberry@Dal:~/bridge_ghc_bug$ uname -a
Linux Dal 2.6.18-3-686 #1 SMP Mon Dec 4 16:41:14 UTC 2006 i686 GNU/Linux
pberry@Dal:~/bridge_ghc_bug$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
pberry@Dal:~/bridge_ghc_bug$ ghc -v --make main.hs
Glasgow Haskell Compiler, Version 6.6, for Haskell 98, compiled by GHC version 6.6
Using package config file: /usr/lib/ghc-6.6/package.conf
wired-in package base mapped to base-2.0
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0
wired-in package template-haskell mapped to template-haskell-2.0
Hsc static flags: -static
*** Chasing dependencies:
Chasing modules from: main.hs
Stable obj: []
Stable BCO: []
compile: input file main.hs
Created temporary directory: /tmp/ghc5182_0
*** Checking old interface for main:Main:
[1 of 1] Compiling Main             ( main.hs, main.o )
*** Parser:
*** Renamer/typechecker:

main.hs:30:12:
    No instance for (Show Rank)
      arising from use of `show' at main.hs:30:12-19
    Possible fix: add an instance declaration for (Show Rank)
    In the first argument of `(~?=)', namely `show Ten'
    In the expression: (show Ten) ~?= ""T""
    In the second argument of `($)', namely
	`[(show Two) ~?= ""2"", (show Three) ~?= ""3"", (show Four) ~?= ""4"",
      (show Five) ~?= ""5"", (show Six) ~?= ""6"", (show Seven) ~?= ""7"",
  (show Eight) ~?= ""8"", (show Nine) ~?= ""9"", (show Ten) ~?= ""T"",
}}}

At this point ghc goes into an (apparently) infinite loop outputting spaces.  When I interrupt it using Ctrl-C, it says:

{{{
*** Deleting temp files:
Deleting: /tmp/ghc5182_0/ghc5182_0.s
Warning: deleting non-existent /tmp/ghc5182_0/ghc5182_0.s
*** Deleting temp dirs:
Deleting: /tmp/ghc5182_0
}}}

Here's the file main.hs:

{{{
import System
import Test.HUnit
import Control.Monad
import Data.List

data Card = Card Rank Suit

data Suit = Clubs | Diamonds | Hearts | Spades
    deriving (Enum, Eq)

data Rank = Two | Three | Four | Five | Six | Seven | Eight | Nine | Ten | Jack | Queen | King | Ace
    deriving (Enum, Ord, Eq)

type Hand = [Card]

hand :: String -> Hand
hand = undefined

main = undefined

allTests = test $
           [show Two ~?= ""2""
           ,show Three ~?= ""3""
           ,show Four ~?= ""4""
           ,show Five ~?= ""5""
           ,show Six ~?= ""6""
           ,show Seven ~?= ""7""
           ,show Eight ~?= ""8""
           ,show Nine ~?= ""9""
           ,show Ten ~?= ""T""
           ,hand ""AK76543/32/AK2/3"" ~?= exampleHand
           ]
    where exampleHand = []
}}}",Paul_Berry@…
5,2459,6,dterei,"can't link haskell without ""main"" function, or -no-hs-main broken on windows?",Driver,6.8.2,7.6.2,,new,lowest,2012-09-12T04:14:00-0700,"can't link haskell without ""main"" function, or -no-hs-main broken on windows?

The issue arose when trying to compile wxHaskell examples with a !WinMain entry point in
the executable rather than the standard ""main"" function, thereby stopping a new console
window being created when the application starts up, i.e. creating a ""windows"" application.

luckily (by chance, I think) the desired objective can be achieved without any change to the haskell 
code as follows, with the support that gcc already provides for a !WinMain entry point,
utilising the wxHaskell example:

{{{
> ghc -o HelloWorl.o -fglasgow-exts -c HelloWorld.hs
> ghc -optl-mwindows -o HelloWorld.exe HelloWorld.o -package wxcore
}}}

OK, so what is the issue ? We what if we want to define our own !WinMain or utilise the 
!WinMain or other entry point provided by another object file or code. According to the 
ghc documentation the way it could be achieved would be, with this example ...

!MyHelloWorld.hs ..

{{{
> module Hello where
> 
> foreign export ccall ""runHsMain"" runMain :: IO ()
> 
> runMain = do
>   putStrLn ""Hello World""
}}}

and mymain.c

{{{
#include ""HsFFI.h""
extern void __stginit_Hello ( void );

extern void runHsMain();
 

int main(int argc, char* argv[])
{

 
  hs_init(&argc, &argv);
  hs_add_root(__stginit_Hello);
  runHsMain();

  hs_exit();
  return 0;
}
}}}


{{{
> ghc -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs
> ghc -o hello.exe mymain.c MyHelloWorld.o MyHelloWorld_stub.o
> hello.exe
Hello World
}}}

all works fine, but dosn't ghc documentation say, the -no-hs-main option should be used ? OK so use it

{{{
> ghc -no-hs-main -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs
> ghc  -no-hs-main -o hello.exe mymain.c MyHelloWorld.o MyHelloWorld_stub.o
> hello.exe
Hello World
}}}

OK, works both with and without -no-hs-main, strange?
but how about if we want to define our own !WinMain or dllMain etc (i.e. no main at all)

winmain.c:

{{{
#include <windows.h>
#include ""HsFFI.h""
extern void __stginit_Hello ( void );

extern void runHsMain();
 
int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, 
    LPSTR lpszCmdLine, int nCmdShow) 
{ 
 
  hs_init(0, 0);
  hs_add_root(__stginit_Hello);

  hs_exit();
  return 0;
}
}}}

you can use the above haskell hello example or the wxHaskell !HelloWorld example 
but with edits to main/module name as per !MyHelloWorld, call it !MyHelloWorldW.
But the above Haskell suffices as a test case, and is used in the
following.

linking with winmain, we get this error:

{{{
>ghc -no-hs-main -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o
C:/apps/ghc/6.8.2/libHSrts.a(Main.o)(.text+0x7):Main.c: undefined reference to `
__stginit_ZCMain'
C:/apps/ghc/6.8.2/libHSrts.a(Main.o)(.text+0x36):Main.c: undefined reference to
`ZCMain_main_closure'
collect2: ld returned 1 exit status
}}}

it appears ghc does something like this (normal operation, for a standard haskell main)

 * create bootstrapping that initialises the ghc runtime and adds the root !__stginit_ZCMain, and runs the haskell main
 * create a ""c"" main that calls/executes the bootstrapping code
 * the executables entry point will be set by default to the ""c"" ""main"" procedure 

it seems that linking the haskell object with an object that already contains a main symbol will:

 * suppress the creation of bootstrapping code
 * executable entry point still set to the default (""main"")

this behaviour is exhibitted regardless of -no-hs-main option

When the haskell objects are linked with other objects and even though -no-hs-main option is 
specified it appears that ghc:

 * creates bootstrapping that initialises the ghc runtime and adds the root !__stginit_ZCMain, and runs the haskell main
 * creates a main that calls/executes the bootstrapping code
 * executable entry point still set to the default (""main"")

i.e. the same behaviour as for ""normal"" execution, this behaviour appears wrong, the behaviour should be:

 * suppress the creation of bootstrapping code (initialisation of haskell
 should be the responsibility of the external code, per guidlines)
 * executable entry point still set to default

i.e., as in the above example hs_add_root initialises the root module (!__stginit_Hello)
and there is no requirement for an !__stginit_ZCMain.


you can get the above example to compile and link with ...

{{{
>ghc -main-is Hello.runMain -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs

>ghc -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o
}}}

but if this is the wxHaskell !HelloWorld example, you would see that the it still starts up as a console
application and not a !WinMain (windows) application.

the effect of using th -main-is option is to insert a ""!___stginit_ZCMain"" symbol into the !HelloWorld.o
object. A ""c"" ""main"" will be created, initialising haskell and invoking the haskell main Hell.runMain. 
The entry point of the executable will be this ""main"", i.e. regard,

[link with ldl-mwindows to set entry to win32,see what happens]
{{{
> ghc -main-is Hello.runMain -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs

> ghc -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o
}}}

the above will compile and run but, will not invoke the winmain, rather it will invoke the
automatically generated ""main"".

the following

{{{
> ghc -main-is Hello.runMain -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs
> ghc -optl-mwindows -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o

>winhello
}}}

will invoke the !WinMain routine as a windows application, (in this example a popup will be displayed
reporting an error ""hPutChar invalid arg bad file descriptor"", as it should), ignoring the haskell
supplied main/init.
 
BUT you shouldn't have to compile the haskell module with -main-is ... in order to get the overall exe to link , i.e. the following should work

{{{
>ghc -no-hs-main -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs
>ghc -optl-mwindows -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o
}}}

but we get ...

{{{
C:/apps/ghc/6.8.2/libHSrts.a(Main.o)(.text+0x7):Main.c: undefined reference to `
__stginit_ZCMain'
C:/apps/ghc/6.8.2/libHSrts.a(Main.o)(.text+0x36):Main.c: undefined reference to
`ZCMain_main_closure'
collect2: ld returned 1 exit status
}}}

what should be:

 * no-hs-main option should suppress the requirement for a !___stginit_ZCMain symbol, this should enable
  the linking of, and specification of an arbitrary entry point into the executable external to the
  haskell code.

i.e. the last example should work.

the -optl-mwindows on the ghc command line we can flip the .exe entry point for the executable to a windows
entry point, gcc seems to handle it as follows: if the above -mwindows option is given then the entry point
of the executable is set to !WinMainCRTStartup, which in turn calls the !WinMain function (if present) or
the supplied main, it also sets the subsystem to windows.",jvl
5,2710,6,dterei,-main-is flag in {-# OPTIONS #-} pragma not fully supported,Compiler,6.8.3,7.6.2,,new,lowest,2012-09-12T04:14:03-0700,"The `-main-is` flag is dynamic an may therefore be placed inside the `{-# OPTIONS #-}` pragma. Version 6.8.3 of ''runghc'' respects this flag (that is, ''runghc'' works as expected), but this cannot be said of ''ghc''.

=== Example file ''T.hs'' ===

{{{
{-# OPTIONS -main-is T.main #-}

module T where

main :: IO ()
main = putStrLn ""Hello world""
}}}

=== Example execution ===

{{{
$ ghc --make -o t T.hs
[1 of 1] Compiling T                ( T.hs, T.o )
Warning: output was redirected with -o, but no output will be generated
because there is no Main module.
}}}

=== Additional notes ===

This bug is related to ticket #1312, but the difference is that ticket #1312 only addressed ''runghc'', not ''ghc''.",Stephan202
5,2460,6,dterei,provide -mwindows option like gcc,Compiler,6.8.2,7.6.2,,new,lowest,2012-09-12T04:14:00-0700,"provide a command line option -mwindows (aka main windows) to compile and link the code as a windows executable (i.e. WinMain). This is mearly a matter of passing through the option to gcc and would be trivial to implement. see #2459 for full discussion.

Why Bother ?

To enahnce ""User Friendliness"" and encourage gui users on win32 aka wxHaskell and Gtk2Hs users to produce application with ""Native"" look and feel.",jvl
2,7320,5,tibbe,GHC crashes when building on 32-bit Linux in a Linode,Runtime System,7.6.1,7.6.2,simonmar,new,high,2012-12-07T07:32:57-0800,"
Trying to build {{{haskell-src-exts}}} crashes in a 32-bit Linux Linode (under Xen).

GHC 7.0.4 seems ok, but I've tried GHC 7.2.2, 7.4.1 and 7.6.1 and they all either segfault or issue a bad instruction when building. This also happens when building GHC from source. 

GHC 7.6.1 crashes more frequently than the others. When run under GDB it usually dies at the same program point (0x093c6263). Running GHC with -v says it's in the 'Tidy Core' stage.

I've tried under the latest Arch, as well as Debian. The Linode has 1GB of real RAM and 4GB of swap, so it shouldn't be running out of memory.

The Linode has been stable otherwise, it runs apache and trac, and has had uptimes of 3 months or more.

Running Ubuntu-32bit under Parallels (using OSX as the host) with the same memory configuration seems fine.
",benl
4,1928,5,claus,Confusing type error message,Compiler (Type checker),6.8.1,_|_,,new,low,2008-09-30T08:52:09-0700,"The following code (which is part of a bigger module) needs scoped type variables to compile.

{{{
run_state :: forall a s. State s a -> s -> (a,s)
run_state m s = observe_monad unit_op bind_op m where
  unit_op v          = (v,s)
  bind_op :: BindOp (StateE s) a (a,s)
  bind_op Get      k = run_state (k s) s
  bind_op (Put s1) k = run_state (k ()) s1
}}}
However, forgetting to turn on scoped type variables will give a very confusing error message:
{{{
Unimo.hs:56:36:
    Couldn't match expected type `s1' against inferred type `s'
      `s1' is a rigid type variable bound by
           the type signature for `bind_op' at Unimo.hs:55:28
      `s' is a rigid type variable bound by
          the type signature for `run_state' at Unimo.hs:52:22
    In the first argument of `k', namely `s'
    In the first argument of `run_state', namely `(k s)'
    In the expression: run_state (k s) s
}}}
Line 52 is the type signature of run_state and line 55 is the type signature of bind_op. The error message talks about a type variable `s1' which isn't mentioned anywhere. I guess the reason for this is that we have name collision and this is ghc's way of trying to tell the two variables apart. I don't think it works that well though. But I'm afraid I don't have any suggestion on how to make it better.",josef
5,2365,5,claus,Warn about suspicious flags in OPTIONS_GHC pragmas,Compiler,6.8.2,7.6.2,,new,lowest,2013-01-27T11:13:03-0800,"We should warn if suspicious flags are given in `OPTIONS_GHC` pragmas; in particular, if any `-XLanguage` flag is used.",igloo
5,1880,5,claus,Unify flag descriptions to generate both docs and code,Compiler,6.8.1,7.6.2,,new,lowest,2013-01-26T15:17:59-0800,"We want to specify all of GHC's flags in one place, and from there

 * Generate the flag reference section of the documentation
 * Generate the code to parse the command-line
 * Allow flags to be deprecated, generating a warning
 * Have an option to list all the flags that GHC supports (see #1226)
   for use in command-line completion
 * Generate the man page
 * Completion in GHCi

This ticket replaces part of #1226.",simonmar
3,1147,4,SamB,Quadratic behaviour in the compacting GC,Runtime System,6.6,_|_,,new,normal,2013-01-22T08:54:16-0800,"Run the following program under GHCi with `+RTS -c -RTS`:

{{{
module Main where

break2 p (x:xs) = if p x then 
                    ([],x:xs)
                  else
                    let (b1,b2) = break2 p xs
                    in  (x : b1, b2)
break2 p []     = ([],[])

surprise xs = b1 ++ ""\n surprise "" ++ b2
               where
               (b1,b2) = break2 (=='\n') xs

test n = length $ surprise $ [head (show i) | i <-[1..n] ] ++ ""\n the end""

main = print $ test 1000000
}}}

Notice how it hangs.

This is because of the call to `get_threaded_info()` in `thread_PAP_payload()` in the compacting GC.  We have a lot of APs pointing to the same BCO, so the thread gets really long, and needs to be unravelled for every AP.  One partial fix would be to cache the fun's info table in the spare field of an AP during the mark phase; this fixes the problem for APs, but not for PAPs (which don't have a spare field).

Related to this is the `get_threaded_info()` call in `update_fwd_compact()`, which is inefficient, but not quadratic.  It would be nice to fix this too.",simonmar
3,1444,4,SamB,Template Haskell: add proper support for qualified names in non-splicing applications,Template Haskell,6.6.1,_|_,,new,normal,2013-01-22T08:12:38-0800,"For the uninitiated, Derive is an application of Template Haskell that can generate external Haskell code (depending on how you use it) instead of having it spliced into a module. Template Haskell was not designed for this, and it shows in the handling of qualified names. For example:

{{{
Prelude> '[]
GHC.Base.[]
Prelude> 'True
GHC.Base.True
Prelude> '(*)
GHC.Num.*
Prelude Data.Array.Unboxed> ''UArray
Data.Array.Base.UArray
}}}

It would be nice if Template Haskell could instead use public names, where available, so that Derive and similar tools would be able to use qualified names (and the quoting syntax without fear of their ending up pointing into the middle of no-mans-land, or even GHC-only land.

This would also mean that users of Derive via TH splicing wouldn't need to import so many modules that the derivings depend on.",SamB
3,2200,4,SamB,big static random access arrays,Compiler,6.8.2,_|_,,new,normal,2008-09-30T08:54:54-0700,"
These would be unlike `StorableArray`s because they would be available at compile time, and would be pure values. They would amount to arrays of bytes, of course, but it'd be nice if they could be `(Storable a) => StaticArray a` and we could walk down them or randomly access them to get the `a` values out of them. They should be capable of storing hundreds of thousands of `Int`s.

What are some functions that work on these arrays? We need just one:
{{{
indexInto :: (Storable a) => StaticArray a -> Word -> a
}}}

Then we can make a `Monad` to walk up and down the array. It will be some `State` hybrid. No `IO`. A bright person could implement static `Trie`s, `RoseTree`s and other things using this `Monad` -- storing the offsets mixed in with the data in an unholy mess and skipping forward or backward, leveraging ""the world’s most beautiful imperative language.""

It's been suggested (SamB) that this should be implemented in Template Haskell.

Important features of this array relative to other arrays and lists in Haskell:

 Specificity of Index::
  A machine `Word` since that contains the finest grained pointer. When indexing into a `Storable a`, the index is multiplied by `sizeOf (undefined :: a)`. 

 Static Nature::
  Exists to facilitate large static constants. The array does not support any append or delete operations, there is no way to change any of its values and it can not be copied.",jsnx
5,3107,4,dons,Over-eager GC when blocked on a signal in the non-threaded runtime,Runtime System,6.10.1,7.6.2,,new,lowest,2012-09-12T04:14:08-0700,"Right now, in the non-threaded runtime, if you have the situation where all the threads are blocked on MVars, the deadlock detection / avoidance code runs a GC. This is fine, generally, but if they're blocked on MVars held by signal handlers, it has a profoundly bad effect on performance. In short, the runtime starts collection (blocking signals?), and we're stuck waiting for it to finish before handling signals. Or, if the signal doesn't come in, we sit waiting in a loop, garbage collecting.

It would be nice if the runtime either didn't trigger collection if signal handlers are in place, or, at the very least, held off on doing so for a nontrivial period of time.",awick
5,2215,4,SamB,:disable command to disable breakpoints,GHCi,6.9,7.6.2,,new,lowest,2013-01-29T08:35:50-0800,"Okay, I've finally gotten around to trying the debugger, and I noticed that there don't seem to be any commands to disable or reenable breakpoints. These would be really nice, and probably not too difficult. The names should be {{{:disable}}}and {{{:enable}}}. (That's what I expected them to be.)

Man, I wish there was a severity between ""normal"" and ""major""...",SamB
4,5219,2,rl,need a version of hs_init that returns an error code for command-line errors,Runtime System,7.0.3,7.6.2,,new,low,2012-09-12T04:13:29-0700,"This ticket is extracted from Roman's comment in #4464:

`hs_init` simply aborts if it doesn't like the RTS arguments which is quite unhelpful for dynamic libraries. I took me a day to find out that an application crash was caused by a failing hs_init (because of the -rtsopts problem). I would like to add a check for this to our code but there doesn't seem to be a way to do this. It would be much nicer if hs_init returned a failure/success code, at least for dynamic libraries. 

To which I responded:

If hs_init needs to return an error condition rather than aborting, then we need to define a new API for that, and fix setupRtsFlags. I don't think we need to do this for every case of stg_exit and certainly not for barf: these are all internal error conditions and we have no sensible way to recover.
",simonmar