GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?status=!closed&version=7.6.2&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&version=7.6.2&order=priority
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/7679
http://ghc.haskell.org/trac/ghc/ticket/7679#7679: Regression in -fregs-graph performanceMon, 11 Feb 2013 08:22:56 GMTsimonmar<p>
Likely due to a bad interaction with the new code generator, see <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/7192" title="bug: Bug in -fregs-graph with -fnew-codegen (closed: fixed)">#7192</a>.
</p>
<p>
<tt>-fregs-graph</tt> used to be on by default with <tt>-O2</tt>, but is currently off due to this issue.
</p>
<p>
Results courtesy of @tibbe:
</p>
<pre class="wiki">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%
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/7679#changelog
http://ghc.haskell.org/trac/ghc/ticket/7611
http://ghc.haskell.org/trac/ghc/ticket/7611#7611: Rewrite rules application prevented by type variable application (map id vs. map (\x -> x))Mon, 21 Jan 2013 08:30:39 GMTnomeata<p>
I’m moving the discussion from
<a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-users/2013-January/023522.html"><span class="icon"></span>http://www.haskell.org/pipermail/glasgow-haskell-users/2013-January/023522.html</a> (with reply at <a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-users/2013-January/023531.html"><span class="icon"></span>http://www.haskell.org/pipermail/glasgow-haskell-users/2013-January/023531.html</a>) here, as a reminder for myself to work on it someday:
</p>
<p>
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.
</p>
<p>
I’ll attach a test case.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7611#changelog
http://ghc.haskell.org/trac/ghc/ticket/7650
http://ghc.haskell.org/trac/ghc/ticket/7650#7650: can't use combining characters in identifiersFri, 01 Feb 2013 18:14:42 GMTguest<p>
ghc doesn't let me use combining characters in unicode identifiers. Here's a test case with U+308 (COMBINING DIAERESIS) but it affects all accents:
</p>
<pre class="wiki">% cat comb.hs
main = print spın̈alTap
where spın̈alTap = 11
</pre><pre class="wiki"> % ghc comb.hs
[1 of 1] Compiling Main ( comb.hs, comb.o )
comb.hs:1:18: lexical error at character '\776'
</pre><p>
(This is actually with ghc 7.6.2 but the <tt>Version</tt> drop-down only goes up to 7.6.1.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7650#changelog
http://ghc.haskell.org/trac/ghc/ticket/7666
http://ghc.haskell.org/trac/ghc/ticket/7666#7666: excessive space and time usage for rendering (somewhat) deeply nested DocsWed, 06 Feb 2013 10:35:46 GMTj.waldmann<p>
I was running into serious performance problems when printing moderately sized Doc and Xml data (HaXml goes via Doc).
</p>
<p>
Since pretty is shipped with ghc, this is potentially dangerous. Users will just assume that these core components are tried and tested, and working efficiently.
</p>
<p>
More info:
<a class="ext-link" href="http://article.gmane.org/gmane.comp.lang.haskell.cafe/103210"><span class="icon"></span>http://article.gmane.org/gmane.comp.lang.haskell.cafe/103210</a>
</p>
<p>
See also:
<a class="ext-link" href="http://stackoverflow.com/questions/9761507/which-pretty-print-library"><span class="icon"></span>http://stackoverflow.com/questions/9761507/which-pretty-print-library</a>
</p>
<p>
Test case (builds an Xml tree with HaXml and renders it via the pretty library):
<a class="ext-link" href="https://github.com/jwaldmann/haskell-tpdb/blob/master/test/speed.hs"><span class="icon"></span>https://github.com/jwaldmann/haskell-tpdb/blob/master/test/speed.hs</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7666#changelog
http://ghc.haskell.org/trac/ghc/ticket/7668
http://ghc.haskell.org/trac/ghc/ticket/7668#7668: Location in -fdefer-type-errorsWed, 06 Feb 2013 18:28:49 GMTmonoidal<p>
Consider
</p>
<pre class="wiki">x :: Char
x = 'x' + 1
y :: Char
y = 'y' + 1
</pre><p>
Run <tt>ghci -fdefer-type-errors</tt>:
</p>
<pre class="wiki">*Main> x
*** Exception: G.hs:5:9:
No instance for (Num Char) arising from a use of `+'
In the expression: 'y' + 1
In an equation for `y': y = 'y' + 1
(deferred type error)
*Main> y
*** Exception: G.hs:5:9:
No instance for (Num Char) arising from a use of `+'
In the expression: 'y' + 1
In an equation for `y': y = 'y' + 1
(deferred type error)
</pre><p>
The first exception is wrong. It seems that the missing <tt>Num Char</tt> instance is filled with the same error message in all places where the constraint should be supplied.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7668#changelog
http://ghc.haskell.org/trac/ghc/ticket/7788
http://ghc.haskell.org/trac/ghc/ticket/7788#7788: Recursive type family causes <<loop>>Sat, 23 Mar 2013 04:18:09 GMTshachaf<p>
This file:
</p>
<pre class="wiki">{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UndecidableInstances #-}
data Proxy a = Proxy
foo :: Proxy (F (Fix Id)) -> ()
foo = undefined
newtype Fix a = Fix (a (Fix a))
newtype Id a = Id a
type family F a
type instance F (Fix a) = F (a (Fix a))
type instance F (Id a) = F a
main :: IO ()
main = print $ foo Proxy
</pre><p>
Dies with <tt><<loop>></tt>. The type family is recursive, of course:
</p>
<pre class="wiki">*Main> :kind! F (Fix Id)
F (Fix Id) :: *^CInterrupted.
</pre><p>
But <tt><<loop>></tt> is still not the behavior I'd expect. The actual value is just <tt>undefined</tt>.
</p>
<p>
In the file that this example came up, the situation was even worse -- there was a situation where
</p>
<pre class="wiki">moldMapOf l f = runAccessor . l (Accessor . f)
main = print $ (flip appEndo [] . moldMapOf (ix 3) (Endo . (:)) $ testVal :: [Int]) -- <<loop>>
main = print $ (flip appEndo [] . runAccessor . (ix 3) (Accessor . Endo . (:)) $ testVal :: [Int]) -- undefined
</pre><p>
I.e. substitution can turn one program (which happens to be ⊥ here, admittedly, but that's not fundamental) into another (<tt><<loop>></tt>). This makes it very tricky to track down the recursive type family. If necessary I can hunt down a working test case and post it here -- it's a bit tricky to get working, though.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7788#changelog
http://ghc.haskell.org/trac/ghc/ticket/7803
http://ghc.haskell.org/trac/ghc/ticket/7803#7803: Superclass methods are left unspecializedTue, 02 Apr 2013 01:14:30 GMTakio<p>
In the attached code, Foo.foo1 gets compiled (by ghc -O2) into a call to the unspecialized version of Lib.exp5Tail, even though all the related functions are marked INLINE or SPECIALIZE.
</p>
<p>
The problem seems to be that GHC creates a top-level overloaded function after the specialization pass, so the function never gets specialized.
</p>
<p>
This might be the same issue as <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/7785" title="bug: Module-local function not specialized with ConstraintKinds (closed: fixed)">#7785</a>, but the workaround I posted there does not work here.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7803#changelog
http://ghc.haskell.org/trac/ghc/ticket/7808
http://ghc.haskell.org/trac/ghc/ticket/7808#7808: data families and TH names do not mix well (e.g. cannot use TH deriving)Wed, 03 Apr 2013 15:20:02 GMTduncan<p>
lots of Haskell libraries have TH functions like:
</p>
<pre class="wiki">deriveJSON :: Name -> Q [Dec]
</pre><p>
(e.g. aeson package for deriving JSON conversion)
</p>
<p>
They're used like
</p>
<pre class="wiki">data Foo = Foo This That
$(deriveJSON ''Foo)
</pre><p>
the <tt>deriveJSON</tt> reifies the Name and expects to find that the name refers to a data type, from which it finds the data constructors and generates the appropriate code.
</p>
<p>
Now, this doesn't work when the data type we want to derive an instance for is defined using a data family:
</p>
<pre class="wiki">class FooClass a where
data Foo a
...
instance FooClass Bar where
data Foo Bar = Bar This That
$(deriveJSON ''Foo Bar) -- ???
</pre><p>
We'd like to make the type Foo Bar an instance of the class (e.g. To/FromJSON) but <tt>deriveJSON</tt> expects a Name, and there is no name for this data type, its "name" is <tt>Foo Bar</tt> but obviously that's not a <tt>TH.Name</tt>.
</p>
<p>
Of course in general a name for a type application doesn't make sense, but for data family instances what other way do we have to refer to them?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7808#changelog
http://ghc.haskell.org/trac/ghc/ticket/7828
http://ghc.haskell.org/trac/ghc/ticket/7828#7828: RebindableSyntax and ArrowWed, 10 Apr 2013 14:49:38 GMTAlessandroVermeulen<p>
When trying to add constraints to the types of the arrow primitives I get a type error. I think that doing such a thing should be possible and I've attached the code I used to test this. The errors I get when using the arrow notation for the function test are as follows:
</p>
<pre class="wiki">test :: Typeable a => R a a
test = proc n -> returnA -< n
</pre><pre class="wiki">bug-arrow.hs:15:8:
Could not deduce (Typeable c) arising from a use of `arr'
from the context (Typeable a)
bound by the type signature for test :: Typeable a => R a a
at bug-arrow.hs:14:9-27
Possible fix:
add (Typeable c) to the context of
a type expected by the context: (b -> c) -> R b c
or the type signature for test :: Typeable a => R a a
In the expression: arr
When checking that `arr' (needed by a syntactic construct)
has the required type: forall b1 c1. (b1 -> c1) -> R b1 c1
arising from a proc expression at bug-arrow.hs:15:8-29
In the expression: proc n -> returnA -< n
bug-arrow.hs:15:8:
Could not deduce (Typeable c) arising from a use of `>>>'
from the context (Typeable a)
bound by the type signature for test :: Typeable a => R a a
at bug-arrow.hs:14:9-27
Possible fix:
add (Typeable c) to the context of
a type expected by the context: R a1 b -> R b c -> R a1 c
or the type signature for test :: Typeable a => R a a
In the expression: (>>>)
When checking that `(>>>)' (needed by a syntactic construct)
has the required type: forall a2 b1 c1.
R a2 b1 -> R b1 c1 -> R a2 c1
arising from a proc expression at bug-arrow.hs:15:8-29
In the expression: proc n -> returnA -< n
bug-arrow.hs:15:8:
Could not deduce (Typeable d) arising from a use of `first'
from the context (Typeable a)
bound by the type signature for test :: Typeable a => R a a
at bug-arrow.hs:14:9-27
Possible fix:
add (Typeable d) to the context of
a type expected by the context: R b c -> R (b, d) (c, d)
or the type signature for test :: Typeable a => R a a
In the expression: first
When checking that `first' (needed by a syntactic construct)
has the required type: forall b1 c1 d1.
R b1 c1 -> R (b1, d1) (c1, d1)
arising from a proc expression at bug-arrow.hs:15:8-29
In the expression: proc n -> returnA -< n
</pre><p>
When I replace the definition with the translated core code (minus type applications and scoped type variables) the code compiles:
</p>
<pre class="wiki">test :: Typeable a => R a a
test =
(>>>)
(arr (\ (n_apd) -> n_apd))
((>>>)
(arr (\ (ds_dst) -> ds_dst))
(returnA)
)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/7828#changelog
http://ghc.haskell.org/trac/ghc/ticket/7829
http://ghc.haskell.org/trac/ghc/ticket/7829#7829: make better/more robust loopbreaker choicesThu, 11 Apr 2013 18:41:00 GMTnfrisby<p>
The choice of loopbreaker can severely influence downstream compilation. This task ticket is about making the choice more robust/better/"smarter". This ticket is also empty of concrete suggestions how to do so... think of it like a community <span class="wikiextras phrase todo">TODO</span>.
</p>
<p>
One example feature of the current algorithm that seems a bit fragile is the use of two schemes for breaking ties depending on the max "depth" of 2. Peruse the code and its comments and Notes in OccAnal if you're interested.
</p>
<p>
This also ticket serves to document a small regression incurred by my commit <a class="changeset" href="http://ghc.haskell.org/trac/ghc/changeset/af12cf66d1a416a135cb98b86717aba2cd247e1a/ghc" title="ignore RealWorld in size_expr; flag to keep w/w from creating sharing
...">af12cf66d1a416a135cb98b86717aba2cd247e1a</a>. There's a 4% increase in allocation in nofib/rewrite as a result of my change altering the loopbreaker choice.
</p>
<p>
The actual details aren't relevant, but here's the basic story in order to convey the delicacy of loopbreaker choice. My commit slightly reduces the calculated size of a function in a mutually recursive group, so that it comes in under the "never unfold limit" instead of over. This ultimately causes the looperbreaker chooser to break a tie in a different way (there's two "Plans"). The previous choice was more fortuitous: it enabled a beneficial inlining that "misses its chance" with the new choice of loopbreaker.
</p>
<p>
I don't remember nor ever totally understood the details of this last part of the story. I don't have the cycles at the moment to wade into it -dverbose-core2core -ddump-inlings again. Apologies. If a brave soul is interested, you should be able to recover the more fortuitous loopbreaker choice by setting <tt>CoreUnfolding.sizeExpr.isRealWorldId</tt> to <tt>const False</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7829#changelog
http://ghc.haskell.org/trac/ghc/ticket/8014
http://ghc.haskell.org/trac/ghc/ticket/8014#8014: Assertion failure when using multithreading in debug mode.Wed, 26 Jun 2013 22:21:07 GMTMaxander<p>
Using the -debug compiler option in search of a (hopefully unrelated) bug, I've begun to receive the following error message a few seconds after starting my program;
</p>
<pre class="wiki">
Multi: internal error: ASSERTION FAILED: file rts/Schedule.c, line 1311
(GHC version 7.6.2 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted
</pre><p>
When I have time and if this site allows, I'll try to find what precisely in my code is generating the error and add that to this ticket. Until then, what information I can give:
</p>
<ul><li>Running the same executable in non-threaded mode (executing with "+RTS N1" rather than "+RTS N2" or greater) produces no error.
</li></ul><ul><li>The program calls into C using the FFI interface, and there is also a callback from C back into Haskell. This would be happening around when the error occurs.
</li></ul><ul><li>For reasons I presume to have to do with the C++ code, the program segfaults after extended execution; this is the hopefully unrelated bug I was after when I found this.
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8014#changelog
http://ghc.haskell.org/trac/ghc/ticket/8281
http://ghc.haskell.org/trac/ghc/ticket/8281#8281: The impossible happened: primRepToFFITypeFri, 13 Sep 2013 00:22:18 GMTtibbe<p>
I ran into this error while trying to use GHCi on the hashable package:
</p>
<pre class="wiki">$ cabal repl
Preprocessing library hashable-1.2.0.10...
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.
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package bytestring-0.10.0.2 ... linking ... done.
Loading package text-0.11.3.1 ... linking ... done.
Loading object (static) dist/build/cbits/fnv.o ... done
Loading object (static) dist/build/cbits/getRandomBytes.o ... done
final link ... done
[1 of 4] Compiling Data.Hashable.RandomSource ( Data/Hashable/RandomSource.hs, interpreted ) [flags changed]
[2 of 4] Compiling Data.Hashable.Class ( Data/Hashable/Class.hs, interpreted ) [flags changed]
ghc: panic! (the 'impossible' happened)
(GHC version 7.6.2 for x86_64-apple-darwin):
primRepToFFIType
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8281#changelog
http://ghc.haskell.org/trac/ghc/ticket/8828
http://ghc.haskell.org/trac/ghc/ticket/8828#8828: Type pattern synonymsThu, 27 Feb 2014 00:56:42 GMTaavogt<p>
Hi, it would be nice if the following example were acceptable:
</p>
<pre class="wiki">{-# LANGUAGE FlexibleInstances, TypeFamilies, TypeSynonymInstances #-}
data X a = X a
type family TX a
type instance TX a = X a
instance Show (TX Int)
</pre><p>
But ghc complains that it cannot substitute the instance of TX:
</p>
<pre class="wiki">ts.hs:6:10:
Illegal type synonym family application in instance: TX Int
In the instance declaration for ‛Show (TX Int)’
</pre><p>
A more practical (but not self-contained) example involving extensible records looks <a class="ext-link" href="http://lpaste.net/100436"><span class="icon"></span>http://lpaste.net/100436</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8828#changelog