GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?status=!closed&cc=~rl&order=priority
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/query?status=!closed&cc=~rl&order=priority
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/1409
http://ghc.haskell.org/trac/ghc/ticket/1409#1409: Allow recursively dependent modules transparently (without .hs-boot or anything)Mon, 04 Jun 2007 13:42:28 GMTIsaac Dupree<p>
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).
</p>
<p>
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).
</p>
<p>
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.
</p>
<p>
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: <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/930" title="bug: ghc-6.6: panic! (the 'impossible' happened) mkWWcpr: not a product ... (closed: fixed)">#930</a> , <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1072" title="bug: Core Lint Errors: in result of Desugar (closed: fixed)">#1072</a> , <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1133" title="bug: auto-derivation of Enum is disallowed with recursive imports (closed: fixed)">#1133</a> . 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.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1409#changelog
http://ghc.haskell.org/trac/ghc/ticket/2595
http://ghc.haskell.org/trac/ghc/ticket/2595#2595: Implement record update for existential and GADT data typesMon, 15 Sep 2008 14:00:45 GMTsimonpj<p>
Ganesh writes: The most important thing for me is supporting record update for
existentially quantified data records, as in the error below.
</p>
<p>
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.
</p>
<p>
I don't understand this stuff well enough to be sure whether it's an
impredicativity issue or not, though.
</p>
<pre class="wiki">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}
</pre><p>
Program is:
</p>
<pre class="wiki">{-# 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 }
</pre><p>
Simon says: Ah now I see. The relevant comment, <tt>TcExpr</tt> line 465, says
</p>
<pre class="wiki">-- Doing record updates on
-- GADTs and/or existentials is more than my tiny
-- brain can cope with today
</pre><p>
Should be fixable, even with a tiny brain.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2595#changelog
http://ghc.haskell.org/trac/ghc/ticket/5470
http://ghc.haskell.org/trac/ghc/ticket/5470#5470: The DPH library needs to support PData and PRepr instances for more than 15-tuplesThu, 08 Sep 2011 07:35:15 GMTchak<p>
Currently, <tt>Data.Array.Parallel.PArray.PDataInstances</tt> 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 <tt>VectMonad.lookupFamInst: not found</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5470#changelog
http://ghc.haskell.org/trac/ghc/ticket/5539
http://ghc.haskell.org/trac/ghc/ticket/5539#5539: GHC panic - Simplifier ticks exhaustedSat, 08 Oct 2011 22:05:07 GMThvr<p>
When trying to install <tt>blaze-builder</tt> with a freshly installed GHC 7.3.20111007 linux/amd64 build, the following panic occurs:
</p>
<pre class="wiki">$ 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
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/5539#changelog
http://ghc.haskell.org/trac/ghc/ticket/6018
http://ghc.haskell.org/trac/ghc/ticket/6018#6018: Injective type familiesWed, 18 Apr 2012 16:22:24 GMTlunaris<p>
Injective type families have been discussed several times on the mailing list and identified as a potentially useful feature.
</p>
<p>
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.
</p>
<p>
In summary, my changes are:
</p>
<ul><li>Add a new keyword, <tt>injective</tt>, which is available only when the <tt>TypeFamilies</tt> extension is enabled. Injective families may then be defined thus:
</li></ul><pre class="wiki"> injective family F a :: *
type instance F Int = Bool
type instance F Bool = Int
injective family G a :: *
type instance G a = a
</pre><blockquote>
<p>
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.
</p>
</blockquote>
<ul><li>Add the constructor <tt>InjFamilyTyCon</tt> to <tt>TyConRhs</tt> and the family flavour <tt>InjectiveFamily</tt> to <tt>HsSyn</tt>. Again, I've opted to encode injectivity as a flavour rather than (say) a <tt>Bool</tt> attached to type families. This is a completely arbitrary choice and may be utterly stupid.
</li></ul><ul><li>Altered the definition of decomposable <tt>TyCon</tt>s to include injective families (<tt>isDecomposableTyCon</tt>). This effectively introduces a typing rule that says if we have <tt>(F a ~ F b)</tt> then we can deduce <tt>(a ~ b)</tt> (<tt>TcCanonical</tt>).
</li></ul><ul><li>Modified the unifier so that it will attempt to replace saturated injective families with their left-hand sides where possible (<tt>TcUnify</tt>). This means that in a function such as:
</li></ul><pre class="wiki"> f :: F a -> F a
f = ...
</pre><blockquote>
<p>
The type of <tt>f False</tt> is inferred as <tt>F Int</tt> (i.e., <tt>a</tt> is no longer ambiguous).
</p>
</blockquote>
<p>
Some things work, some things don't. For example, the attached file typechecks, but if I actually try to evaluate <tt>f False</tt> I get nothing (not even a Segmentation fault).
</p>
<p>
See what you think.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/6018#changelog
http://ghc.haskell.org/trac/ghc/ticket/3782
http://ghc.haskell.org/trac/ghc/ticket/3782#3782: Data Parallel "Impossible happened" compiler errorWed, 23 Dec 2009 21:41:17 GMTguest<p>
When I attempted to compile my vectorized code , I got the following message:
</p>
<pre class="wiki">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
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3782#changelog
http://ghc.haskell.org/trac/ghc/ticket/4081
http://ghc.haskell.org/trac/ghc/ticket/4081#4081: Strict constructor fields inspected in loopWed, 19 May 2010 12:21:26 GMTrl<p>
Here is a small example to illustrate the problem:
</p>
<pre class="wiki">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)
</pre><pre class="wiki">module U where
import T
bar :: Int -> Int -> Int
bar s k = foo s k + 1
</pre><p>
Relying on LiberateCase seems to be the only way to unbox <tt>m</tt> outside of the loop in <tt>bar</tt>. The seq in <tt>foo</tt> doesn't help because it gets eliminated immediately.
</p>
<p>
GHC does have enough information to do this:
</p>
<pre class="wiki">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)] _ ->
...
</pre><p>
Note the demand on <tt>m</tt>. If it was an argument instead of a local binding, it would be unboxed by w/w.
</p>
<p>
Also, the seq does help if we use lazy pairs instead of strict ones.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4081#changelog
http://ghc.haskell.org/trac/ghc/ticket/5219
http://ghc.haskell.org/trac/ghc/ticket/5219#5219: need a version of hs_init that returns an error code for command-line errorsWed, 25 May 2011 15:25:42 GMTsimonmar<p>
This ticket is extracted from Roman's comment in <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4464" title="bug: RTS options broken for dynamic libraries (closed: fixed)">#4464</a>:
</p>
<p>
<tt>hs_init</tt> 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.
</p>
<p>
To which I responded:
</p>
<p>
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.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5219#changelog
http://ghc.haskell.org/trac/ghc/ticket/1894
http://ghc.haskell.org/trac/ghc/ticket/1894#1894: Add a total order on type constructorsWed, 14 Nov 2007 19:22:11 GMTguest<p>
Several proposals for <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/ExtensibleRecords">ExtensibleRecords</a> can be implemented as libraries if type constructors can be ordered globally.
</p>
<p>
This proposal is to add built-in types:
</p>
<pre class="wiki">data LabelLT
data LabelEQ
data LabelGT
type family LabelCMP
</pre><p>
such that, for any two datatypes
</p>
<pre class="wiki">data N = N
data M = M
</pre><p>
the instance <tt>LabelCMP N M</tt> takes one of the values <tt>LabelLT, LabelEQ, LabelGT</tt> depending on the lexicographic ordering on the fully-qualified names of <tt>N</tt> and <tt>M</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1894#changelog
http://ghc.haskell.org/trac/ghc/ticket/2598
http://ghc.haskell.org/trac/ghc/ticket/2598#2598: Avoid excessive specialisation in SpecConstrTue, 16 Sep 2008 09:37:31 GMTsimonpj<p>
This ticket captures an email thread so it doesn't get lost.
</p>
<p>
Consider this (from <tt>haddock/src/Haddock/Backends/Hoogle.hs</tt>):
</p>
<pre class="wiki">dropComment (' ':'-':'-':' ':_) = []
dropComment (x:xs) = x : dropComment xs
dropComment [] = []
</pre><p>
This desugars thus:
</p>
<pre class="wiki">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 -> ...
[] -> ...
</pre><p>
I have elided the branches that are less interesting, and I have done a bit of multi-level pattern matching to save space.
</p>
<p>
The thing to notice is this: at the recursive call, we know that the argument is a cons, with C# at the front. So <tt>SpecConstr</tt> dutifully creates a specialized version. And similarly for <em>each subsequent character</em>! Indeed, if the match fails after matching <tt>(' ': '-' : )</tt> prefix, the recursive call even knows that the first char is <tt>'-'</tt>!
</p>
<p>
Hence we get as many specializations as we have characters in the input match.
</p>
<p>
So <tt>SpecConstr</tt> 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.
</p>
<p>
Any thoughts?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2598#changelog
http://ghc.haskell.org/trac/ghc/ticket/3960
http://ghc.haskell.org/trac/ghc/ticket/3960#3960: ghc panic when attempting to compile DPH codeMon, 05 Apr 2010 22:13:28 GMTjwlato<p>
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
</p>
<pre class="wiki">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})
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3960#changelog