GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?status=!closed&failure=GHC+rejects+valid+program&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&failure=GHC+rejects+valid+program&order=priority
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/8168
http://ghc.haskell.org/trac/ghc/ticket/8168#8168: ghc "Simplifier ticks exhausted" "When trying UnfoldingDone"Sat, 24 Aug 2013 06:44:03 GMTsp55aa<p>
ghc fail to compile this file:
</p>
<pre class="wiki">---- begin Y.hs ----
newtype Rec a = Rec { unRec :: Rec a -> a }
y :: (a -> a) -> a
y = \f -> (\x -> f (unRec x x)) (Rec (\x -> f (unRec x x)))
foo :: (a -> a) -> a -> a
foo f n = f n
main = print $ y foo 4
---- end Y.hs ----
</pre><p>
Try it:
</p>
<pre class="wiki">C:\Users\user\Desktop>ghc Y.lhs
[1 of 1] Compiling Main ( Y.lhs, Y.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.6.3 for i386-unknown-mingw32):
Simplifier ticks exhausted
When trying UnfoldingDone a_sqe{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: 5601
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8168#changelog
http://ghc.haskell.org/trac/ghc/ticket/670
http://ghc.haskell.org/trac/ghc/ticket/670#670: External Core is brokenWed, 25 Jan 2006 07:49:12 GMTKirstenChevalier<pre class="wiki">$ 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/.
</pre><p>
Main.hs consists of:
<tt> main = putStr "Hello world!" </tt>
</p>
<p>
I'll fix this myself if I still have commit access; I just want to have a record of it.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/670#changelog
http://ghc.haskell.org/trac/ghc/ticket/1978
http://ghc.haskell.org/trac/ghc/ticket/1978#1978: Error message: Undefined reference to `XXX_closure'Thu, 13 Dec 2007 16:28:09 GMTAndriy<p>
When I try to compile the following test case:
</p>
<pre class="wiki">import System.IO
import Text.XML.HXT.Arrow
main = do
runX $ application
application =
readDocument [(a_validate, v_0)] "url"
>>> generateItemsXml
-- >>. takeLast
>>. \t -> [last t]
>>> getErrStatus
where
takeLast xs = [last xs]
generateItemsXml = root [] []
</pre><p>
the compilation fails because of the line ">>. \t -> [last t]". If I extract this line into a separate function (here takeLast) or take it into parentheses, the compilation proceeds.
For this test case compilation actually fails later with more sensible error message, but the original full program compiles after this fix successfully. I can provide the full program if necessary. It is not very big. Contact me at c at hlsoft com.
</p>
<p>
The GHC compilation failure is:
</p>
<pre class="wiki">~/prj/pubStats$ ./run.sh
[123 of 123] Compiling Main ( src/testGhc.hs, src/testGhc.o )
Linking src/testGhc ...
src/testGhc.o: In function `Main_lvl3_info':
ghc26321_0.hc:(.text+0x166): undefined reference to `Main_application_closure'
src/testGhc.o:(.rodata+0x10): undefined reference to `Main_application_closure'
collect2: ld returned 1 exit status
</pre><p>
The GHCi fails with following message:
</p>
<pre class="wiki">During interactive linking, GHCi couldn't find the following symbol:
Main_application_closure
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
</pre><p>
The GHC version:
"The Glorious Glasgow Haskell Compilation System, version 6.6" on Ubuntu Linux 7.04. Currently I don't have time to try to reproduce the problem on the latest version of the compiler.
</p>
<p>
I compile my program with the HXT library using the following command:
</p>
<pre class="wiki">ghc --make -O -fglasgow-exts -farrows -iinc src/testGhc.hs
</pre><p>
where the inc directory contains the HXT library.
Sorry if it is not a bug, or it is already fixed. I could not decide whether other occurrences of this error indicate the same problem. Decided that submitting an invalid bug is better than missing it completely.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1978#changelog
http://ghc.haskell.org/trac/ghc/ticket/4347
http://ghc.haskell.org/trac/ghc/ticket/4347#4347: Bug in unification of polymorphic and not-yet-polymorphic typeMon, 27 Sep 2010 21:36:08 GMTdolio<p>
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 <tt>($)</tt> where it would have to be instantiated impredicatively.
</p>
<p>
Initially, I thought this was due to a planned removal of impredicativity, but this cannot be the case, because:
</p>
<pre class="wiki">const :: a -> (forall b. b) -> a
</pre><p>
is accepted by the type checker. However, the simple:
</p>
<pre class="wiki">id :: (forall a. a) -> (forall b. b)
</pre><p>
is not, giving an error message:
</p>
<pre class="wiki"> 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)
</pre><p>
This would seem to indicate that the type is being rewritten to:
</p>
<pre class="wiki">forall b. (forall a. a) -> b
</pre><p>
and then the <tt>forall a. a</tt> matched with the bare <tt>b</tt>. 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.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4347#changelog
http://ghc.haskell.org/trac/ghc/ticket/5395
http://ghc.haskell.org/trac/ghc/ticket/5395#5395: Context reduction stack overflow without undecidable instancesTue, 09 Aug 2011 04:19:05 GMTguest<p>
When using type families whose reduction surely terminates (and which are accepted without undecidable instances) GHC still seems to set the context stack reduction limit. See the included code.
</p>
<p>
The fixed limit on context stack size prevents us from doing type-level arithmetic on arbitrarily-sized type-level numerals.
</p>
<p>
If the context-size limit is applied whether undecidable instance
extension is used or not, one may wonder of the purpose of the
undecidable instance extension.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5395#changelog
http://ghc.haskell.org/trac/ghc/ticket/5401
http://ghc.haskell.org/trac/ghc/ticket/5401#5401: LANGUAGE pragma parser nitWed, 10 Aug 2011 06:03:33 GMTnwf<p>
A language pragma like
</p>
<pre class="wiki">{-# LANGUAGE
TypeOperators,
FlexibleContexts #-}
</pre><p>
parses just fine but
</p>
<pre class="wiki">{-# LANGUAGE
TypeOperators,
FlexibleContexts
#-}
</pre><p>
doesn't, saying:
</p>
<pre class="wiki"> Cannot parse LANGUAGE pragma
Expecting comma-separated list of language options,
each starting with a capital letter
</pre><p>
An OPTIONS pragma, on the other hand, accepts either format without complaint.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5401#changelog
http://ghc.haskell.org/trac/ghc/ticket/6016
http://ghc.haskell.org/trac/ghc/ticket/6016#6016: On Windows, runhaskell hits an error on UTF-8 files with a BOMWed, 18 Apr 2012 08:03:29 GMTvsajip<p>
The file
</p>
<pre class="wiki">#!/usr/bin/env runhaskell
main = putStrLn "Hello, world!"
</pre><p>
works on Windows as expected:
</p>
<pre class="wiki">C:\Temp>runhaskell hello.hs
Hello, world!
</pre><p>
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:
</p>
<pre class="wiki">C:\Temp>runhaskell hello2.hs
hello2.hs:1:1: parse error on input `#!/'
</pre><p>
I'm using the Haskell Platform 2011.4.0.0.
</p>
<p>
I believe that runhaskell/runghc should handle the presence of a BOM correctly; some Windows programs insert a BOM unbeknownst to the user.
</p>
<p>
This behaviour was observed on Windows XP (32-bit) and Windows 7 (32-bit and 64-bit).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/6016#changelog
http://ghc.haskell.org/trac/ghc/ticket/6065
http://ghc.haskell.org/trac/ghc/ticket/6065#6065: Suggested type signature causes a type error (even though it appears correct)Mon, 30 Apr 2012 18:02:24 GMTtvynr<p>
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 <a class="missing wiki">OverlappingInstances?</a> 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.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/6065#changelog
http://ghc.haskell.org/trac/ghc/ticket/6089
http://ghc.haskell.org/trac/ghc/ticket/6089#6089: Allow declaration splices inside declaration bracketsFri, 11 May 2012 14:08:48 GMTigloo<p>
I would like to be able to write code like:
</p>
<pre class="wiki">{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH
decs :: Q [Dec]
decs = [d| data MyType = MyCon | MyOtherCon
val1 :: MyType
val1 = MyCon
val2 :: MyType
val2 = MyOtherCon
$( do let mkFun v i = [| if $v == i then val1 else val2 |]
[d| fun3 x = $(mkFun [| x |] 3)
fun4 x = $(mkFun [| x |] 4) |] ) |]
</pre><p>
but GHC says:
</p>
<pre class="wiki">$ ghci decSplices.hs
GHCi, version 7.5.20120420: 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 ( decSplices.hs, interpreted )
decSplices.hs:15:15:
Declaration splices are not permitted inside declaration brackets
Failed, modules loaded: none.
</pre><p>
As far as I can see there is no technical reason why this couldn't work, with a splice within a declaration bracket splitting the declarations into 3. The declarations before the splice would be renamed, typechecked etc first, then those in the splice, and finally those after the splice.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/6089#changelog
http://ghc.haskell.org/trac/ghc/ticket/6132
http://ghc.haskell.org/trac/ghc/ticket/6132#6132: Can't use both shebang line and #ifdef declarations in the same file.Tue, 29 May 2012 12:05:29 GMTgfxmonk<p>
I have an (admittedly awkward) script which can be compiled or interpreted.
</p>
<p>
If it's compiled, I want the full goodness. If it's interpreted, I want to run a "minimal" version (because if I don't have the compiled version, I probably don't have the required libraries either).
</p>
<p>
The following almost works:
</p>
<pre class="wiki">
module Main (main) where
#ifdef FANCY
import qualified System.Console.ANSI as Term
start = Term.setSGR [Term.SetColor Term.Foreground Term.Dull Term.Green]
end = Term.setSGR []
#else
start = return ()
end = return ()
#endif
main :: IO ()
main = do
start
putStrLn "hello world"
end
</pre><p>
and then I can do:
</p>
<pre class="wiki">$ runghc -cpp main.hs
hello world
^^ plain text
</pre><pre class="wiki">$ ghc -O -cpp -DFANCY main.hs
$ ./main
hello world
^^ green text (a.k.a "fancy")
</pre><p>
I attempted to make this directly runnable by adding a shebang line of
</p>
<pre class="wiki">#!/usr/bin/runghc -cpp
</pre><p>
But unfortunately that chokes with -cpp:
</p>
<pre class="wiki">
$ ghc -O -cpp -DFANCY main.hs
main.hs:1:0: error: invalid preprocessing directive #!
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/6132#changelog
http://ghc.haskell.org/trac/ghc/ticket/7026
http://ghc.haskell.org/trac/ghc/ticket/7026#7026: Impredicative implicit parametersSat, 23 Jun 2012 17:36:30 GMTAshley Yakeley<p>
There doesn't seem to be a way to make impredicative implicit parameters work in 7.4.2:
</p>
<pre class="wiki">{-# LANGUAGE ImplicitParams, ImpredicativeTypes #-}
module Bug where
f1 :: Maybe ((?a :: Bool) => Char)
f1 = Just 'C'
f2 :: Maybe ((?a :: Bool) => Bool)
f2 = Just ?a
</pre><pre class="wiki">$ ghc -c Bug.hs
Bug.hs:5:15:
Couldn't match expected type `(?a::Bool) => Char'
with actual type `Char'
In the first argument of `Just', namely 'C'
In the expression: Just 'C'
In an equation for `f1': f1 = Just 'C'
Bug.hs:8:15:
Unbound implicit parameter (?a::(?a::Bool) => Bool)
arising from a use of implicit parameter `?a'
In the first argument of `Just', namely `?a'
In the expression: Just ?a
In an equation for `f2': f2 = Just ?a
</pre><p>
I believe this used to work?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7026#changelog
http://ghc.haskell.org/trac/ghc/ticket/7243
http://ghc.haskell.org/trac/ghc/ticket/7243#7243: regression: acceptable foreign result typesMon, 17 Sep 2012 02:55:46 GMTdmwit<p>
The following short file is rejected:
</p>
<pre class="wiki">import Foreign.Ptr
foreign import ccall "wrapper" foo :: IO (FunPtr ())
</pre><p>
The error is:
</p>
<pre class="wiki">test.hs:2:1:
Unacceptable type in foreign declaration: IO (FunPtr ())
When checking declaration:
foreign import ccall safe "wrapper" foo :: IO (FunPtr ())
</pre><p>
However, my reading of the 2010 Report suggests this should be acceptable. Specifically:
</p>
<ul><li>Prelude.IO t is a marshallable foreign result type when t is a marshallable foreign type,<br />
</li><li>all basic foreign types are marshallable foreign types, and<br />
</li><li><a class="missing wiki">FunPtr?</a> a is a basic foreign type for all a.
</li></ul><p>
(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.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7243#changelog
http://ghc.haskell.org/trac/ghc/ticket/7395
http://ghc.haskell.org/trac/ghc/ticket/7395#7395: DefaultSignatures conflict with default implementationsMon, 05 Nov 2012 19:05:29 GMTcgaebel<p>
Default signatures cannot be used with default implementations.
</p>
<p>
This is quite annoying for the hashable package, as we'd like to provide both options to the user.
</p>
<p>
See the attached test case.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7395#changelog
http://ghc.haskell.org/trac/ghc/ticket/7401
http://ghc.haskell.org/trac/ghc/ticket/7401#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.Fri, 09 Nov 2012 08:33:40 GMTjpbernardy<p>
On a "phantom datatype" D, one gets the message:
</p>
<pre class="wiki">Can't make a derived instance of `Eq D':
`D' must have at least one data constructor
</pre><p>
However there is a trivial, correct instance of Eq D:
</p>
<pre class="wiki">instance Eq D where
(==) = undefined
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/7401#changelog
http://ghc.haskell.org/trac/ghc/ticket/7503
http://ghc.haskell.org/trac/ghc/ticket/7503#7503: Bug with PolyKinds, type synonyms & GADTsSun, 16 Dec 2012 23:37:00 GMTAshley Yakeley<p>
GHC incorrectly rejects this program:
</p>
<pre class="wiki">{-# LANGUAGE ExistentialQuantification, DataKinds, PolyKinds, KindSignatures, GADTs #-}
module TestConstraintKinds where
import GHC.Exts hiding (Any)
data WrappedType = forall a. WrapType a
data A :: WrappedType -> * where
MkA :: forall (a :: *). AW a -> A (WrapType a)
type AW (a :: k) = A (WrapType a)
type AW' (a :: k) = A (WrapType a)
class C (a :: k) where
aw :: AW a -- workaround: AW'
instance C [] where
aw = aw
</pre><p>
GHC accepts the program when AW is replaced with AW' on that line.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7503#changelog
http://ghc.haskell.org/trac/ghc/ticket/7672
http://ghc.haskell.org/trac/ghc/ticket/7672#7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing moduleThu, 07 Feb 2013 19:01:00 GMTskilpat<p>
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 <a class="missing changeset" title="No changeset 2 in the repository">[2]</a>, and so have Im et al. more recently in the context of OCaml <a class="missing changeset" title="No changeset 3 in the repository">[3]</a>.)
</p>
<p>
With that being said, the <em>immediate</em> problem here seems to be that GHC does not actually allow, in the implementing module, the import of its boot file's entities.
</p>
<p>
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.
</p>
<p>
This first example shows that the boot file import is not actually making available the entities it declares:
</p>
<pre class="wiki">module A where
data T
</pre><pre class="wiki">module A where
import {-# SOURCE #-} qualified A as Decl(T)
data T = Z | S Decl.T
</pre><p>
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:
</p>
<pre class="wiki">A.hs:3:18: Not in scope: type constructor or class `Decl.T'
</pre><p>
In an earlier version of GHC I tested, 6.12.1, the error message lies on the import statement:
</p>
<pre class="wiki">A.hs:2:44: Module `A' (hi-boot interface) does not export `T'
</pre><p>
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.)
</p>
<pre class="wiki">module A(Decl.T(..)) where
import {-# SOURCE #-} qualified A as Decl(T)
data T = Z | S T
</pre><p>
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:
</p>
<pre class="wiki">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
</pre><p>
(Making the export list empty shows this second error message only.)
</p>
<p>
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:
</p>
<pre class="wiki">module A(A.T(..)) where
import {-# SOURCE #-} qualified A(T)
data T = Z | S A.T
</pre><p>
A final example shows that, in a module that is <em>not</em> 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.
</p>
<pre class="wiki">module A where
data T
</pre><pre class="wiki">module B(Decl.T(..)) where
import {-# SOURCE #-} qualified A as Decl(T)
data U = U Decl.T
</pre><pre class="wiki">module A(T(..)) where
import qualified B(T)
data T = Z | S B.T
</pre><p>
The error message here, again, lies in the reference B.T in A's implementation:
</p>
<pre class="wiki">A.hs:3:18:
Not in scope: type constructor or class `B.T'
Perhaps you meant `A.T' (line 3)
</pre><p>
Notice, however, that the reference to Decl.T in the B module is perfectly well-formed.
</p>
<p>
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.
</p>
<p>
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 <a class="missing changeset" title="No changeset 4 in the repository">[4]</a> (seem to) corroborate that intended semantics.
</p>
<p>
Your friend in the recursive module swamp,<br />
Scott Kilpatrick
</p>
<hr />
<p>
References
</p>
<p>
<a class="missing changeset" title="No changeset 1 in the repository">[1]</a> Derek Dreyer. <em><a class="ext-link" href="http://www.mpi-sws.org/~dreyer/thesis/main.pdf"><span class="icon"></span>Understanding and Evolving the ML Module System</a></em>, PhD thesis, 2005.<br />
<a class="missing changeset" title="No changeset 2 in the repository">[2]</a> Derek Dreyer. <em><a class="ext-link" href="http://www.mpi-sws.org/~dreyer/courses/modules/dreyer07.pdf"><span class="icon"></span>A Type System for Recursive Modules</a></em>, ICFP 2007.<br />
<a class="missing changeset" title="No changeset 3 in the repository">[3]</a> Hyeonseung Im, Keiko Nakata, Jacques Garrigue, and Sungwoo Park. <em><a class="ext-link" href="http://dl.acm.org/citation.cfm?doid=2048066.2048141"><span class="icon"></span>A syntactic type system for recursive modules</a></em>, OOPSLA 2011.<br />
<a class="missing changeset" title="No changeset 4 in the repository">[4]</a> Iavor S. Diatchki, Mark P. Jones, and Thomas Hallgren. <em><a class="ext-link" href="http://web.cecs.pdx.edu/~mpj/pubs/hsmods.html"><span class="icon"></span>A formal specification of the Haskell 98 module system</a></em>, Haskell 2002.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7672#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/7842
http://ghc.haskell.org/trac/ghc/ticket/7842#7842: Incorrect checking of let-bindings in recursive doWed, 17 Apr 2013 00:00:50 GMTdiatchki<p>
I have run into a problem with the type-checking of recursive do blocks, which reduces to the following example:
</p>
<pre class="wiki">{-# LANGUAGE RecursiveDo #-}
module Bug where
bug :: (Int -> IO Int) -> IO (Bool, Char)
bug m =
mdo i <- m i1 -- RECURSION
let i1 :: Int
i1 = i -- RECURSION
-- This appears to be monomorphic, despite the type signature.
f :: b -> b
f x = x
return (f True, f 'a')
</pre><p>
This program is rejected with the errors shown below. The problem appears to be that somehow <tt>f</tt> has become monomorphic, despite its type-signature. This seems to happen only when <tt>f</tt> is part of a <tt>let</tt> block that is also involved in the recursion.
</p>
<p>
Here is the error reported by GHC 7.7.20130215:
</p>
<pre class="wiki">Bug.hs:15:23:
Couldn't match expected type `Char' with actual type `Bool'
In the return type of a call of `f'
In the expression: f 'a'
In the first argument of `return', namely `(f True, f 'a')'
Bug.hs:15:25:
Couldn't match expected type `Bool' with actual type `Char'
In the first argument of `f', namely 'a'
In the expression: f 'a'
In the first argument of `return', namely `(f True, f 'a')'
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/7842#changelog
http://ghc.haskell.org/trac/ghc/ticket/7862
http://ghc.haskell.org/trac/ghc/ticket/7862#7862: Could not deduce (A) from the context (A, ...)Thu, 25 Apr 2013 07:56:46 GMTalang9<p>
The following code doesn't compile and produces a strange error:
</p>
<pre class="wiki">{-# 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
</pre><pre class="wiki">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)
</pre><p>
Furthermore, Removing the <tt>Num (Scalar t)</tt> constraint from the <tt>Mode</tt> class produces a different strange error:
</p>
<pre class="wiki">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)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/7862#changelog
http://ghc.haskell.org/trac/ghc/ticket/7947
http://ghc.haskell.org/trac/ghc/ticket/7947#7947: Name conflict with DerivingDataTypeable, StandaloneDeriving and qualified importsWed, 29 May 2013 15:02:22 GMTa.ulrich<p>
The bug is triggered by the following minimal example. Types A.A and B.B share a constructor with the same name. Module B is imported qualified, so that the constructors do not conflict.
</p>
<p>
A.hs:
</p>
<pre class="wiki">module A where
data A = C1 | C2 | C
</pre><p>
B.hs:
</p>
<pre class="wiki">module B where
data B = D1 | D2 | C
</pre><p>
C.hs:
</p>
<pre class="wiki">{-# LANGUAGE DeriveDataTypeable #-}
{-# LANGUAGE StandaloneDeriving #-}
module C where
import Data.Data
import Data.Typeable
import A
import qualified B as B
deriving instance Typeable A
deriving instance Typeable B.B
deriving instance Data A
deriving instance Data B.B
main :: IO ()
main = return ()
</pre><p>
When deriving a Data instance for the types, I get a name conflict for some generated code:
</p>
<pre class="wiki">[au@lift ghc-bug]$ ~/Software/ghc-head/bin/ghc --make C.hs
[1 of 3] Compiling B ( B.hs, B.o )
[2 of 3] Compiling A ( A.hs, A.o )
[3 of 3] Compiling C ( C.hs, C.o )
C.hs:12:1:
Duplicate type signatures for ‛$cC’
at C.hs:11:1-24
C.hs:12:1-26
</pre><p>
Note that:
</p>
<ol><li>The problem occurs when deriving Data. Deriving Just the Typeable instance does not produce an error.
</li></ol><ol start="2"><li>Moving the derivation of Typeable and Data to modules A and B respectively works fine.
</li></ol><p>
The problem occurs both in ghc 7.6.2 as well as in ghc head (rev. <a class="changeset" href="http://ghc.haskell.org/trac/ghc/changeset/cfb9bee7cd3e93bb872cbf6f3fa944d8ad5aabf3/ghc" title="Check for illegal syntax in types (fixes Trac #7943)">cfb9bee7cd3e93bb872cbf6f3fa944d8ad5aabf3</a>).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7947#changelog
http://ghc.haskell.org/trac/ghc/ticket/8128
http://ghc.haskell.org/trac/ghc/ticket/8128#8128: Standalone deriving fails for GADTs due to inaccessible codeTue, 13 Aug 2013 09:56:20 GMTadamgundry<p>
Consider the following:
</p>
<pre class="wiki">{-# LANGUAGE StandaloneDeriving, GADTs, FlexibleInstances #-}
module StandaloneDerivingGADT where
data T a where
MkT1 :: T Int
MkT2 :: (Bool -> Bool) -> T Bool
deriving instance Show (T Int)
</pre><p>
This gives the error:
</p>
<pre class="wiki">StandaloneDerivingGADT.hs:9:1:
Couldn't match type ‛Int’ with ‛Bool’
Inaccessible code in
a pattern with constructor
MkT2 :: (Bool -> Bool) -> T Bool,
in an equation for ‛showsPrec’
In the pattern: MkT2 b1
In an equation for ‛showsPrec’:
showsPrec a (MkT2 b1)
= showParen
((a >= 11)) ((.) (showString "MkT2 ") (showsPrec 11 b1))
When typechecking the code for ‛showsPrec’
in a standalone derived instance for ‛Show (T Int)’:
To see the code I am typechecking, use -ddump-deriv
In the instance declaration for ‛Show (T Int)’
</pre><p>
The derived instance declaration matches on all the constructors, even if they cannot possibly match. It should omit obviously inaccessible constructors so that this example is accepted. For reference, the derived code is:
</p>
<pre class="wiki"> instance GHC.Show.Show
(StandaloneDerivingGADT.T GHC.Types.Int) where
GHC.Show.showsPrec _ StandaloneDerivingGADT.MkT1
= GHC.Show.showString "MkT1"
GHC.Show.showsPrec a_aij (StandaloneDerivingGADT.MkT2 b1_aik)
= GHC.Show.showParen
((a_aij GHC.Classes.>= 11))
((GHC.Base..)
(GHC.Show.showString "MkT2 ") (GHC.Show.showsPrec 11 b1_aik))
GHC.Show.showList = GHC.Show.showList__ (GHC.Show.showsPrec 0)
</pre><p>
The same problem applies to other derivable classes (e.g. <tt>Eq</tt>).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8128#changelog
http://ghc.haskell.org/trac/ghc/ticket/8248
http://ghc.haskell.org/trac/ghc/ticket/8248#8248: GHCi should not fail to honour ghci.conf or .ghci if group writableSat, 07 Sep 2013 05:43:35 GMTafcowie<p>
Any number of Linux distros support the idea of user groups, whereby when a new user is created there is also simultaneously a group created with the same name; ie, instead of
</p>
<pre class="wiki">-rw-r--r--. 1 andrew users 19 Sep 5 08:29 ghci.conf
</pre><p>
as us old traditionalists would have it, you get
</p>
<pre class="wiki">-rw-rw-r--. 1 andrew andrew 19 Sep 5 08:29 ghci.conf
</pre><p>
because the umask in such cases is 0002 instead of 0022.
</p>
<p>
There is entirely nothing unusual or incorrect about this approach, and it is followed, for example, in the Fedora family of distros.
</p>
<p>
GHC, however, is being a bit silly in emitting the following:
</p>
<pre class="wiki">$ ghci
GHCi, version 7.6.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.
*** WARNING: /home/andrew/.ghc/ghci.conf is writable by someone else, IGNORING!
Prelude>
</pre><p>
Foremost the fact that the file is group writable is not a problem and the user's choice, <em>particularly</em> in this case because it's group writable in the user's group! Regardless of that, GHCi should not be ignoring files with other than 0644 permissions; this isn't <tt>.ssh/</tt>.
</p>
<p>
Can this check and attendant behaviour be removed?
</p>
<p>
AfC
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8248#changelog
http://ghc.haskell.org/trac/ghc/ticket/8318
http://ghc.haskell.org/trac/ghc/ticket/8318#8318: GHC does not infer type of `tagToEnum#` expressionTue, 17 Sep 2013 15:50:26 GMTjstolarek<p>
Compiling this program:
</p>
<pre class="wiki">{-# LANGUAGE MagicHash #-}
module TTE where
import GHC.Prim
f = case tagToEnum# 1# of
True -> "True"
False -> "False"
</pre><p>
gives a compilation error:
</p>
<pre class="wiki">[1 of 1] Compiling TTE ( tte.hs, tte.o )
tte.hs:6:10:
tagToEnum# must appear applied to one argument
In the expression: tagToEnum# 1#
In the expression:
case tagToEnum# 1# of {
True -> "True"
False -> "False" }
In an equation for ‛f’:
f = case tagToEnum# 1# of {
True -> "True"
False -> "False" }
</pre><p>
To make it work one needs to supply type annotation for <tt>tagToEnum#</tt>: <tt>case tagToEnum# 1# :: Bool of</tt>. I would expect however that type will be inferred from type of patterns in the branches. Although I can imagine that things might get complicated for an ill-typed program:
</p>
<pre class="wiki">f = case tagToEnum# 1# of
True -> "True"
3 -> "What now?"
</pre><p>
If it is not possible to infer type of scrutinee based on patterns then I would expect to get more informative error message. Current one - <tt>tagToEnum# must appear applied to one argument</tt> - is very misleading. When I saw it for the first time it took me about 15 minutes to actually figure out what GHC expects me to do.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8318#changelog
http://ghc.haskell.org/trac/ghc/ticket/8346
http://ghc.haskell.org/trac/ghc/ticket/8346#8346: Rank 1 type signature still requires RankNTypesMon, 23 Sep 2013 14:26:41 GMTtinctorius<p>
When trying to figure out which type variable names are *actually* bound in <tt>ScopedTypeVariables</tt>, I tried floating <tt>forall</tt>s into the covariant argument of the function type. Essentially, I ran into the problem that programs like the following are rejected:
</p>
<div class="code"><pre><span class="cm">{-# LANGUAGE ExplicitForAll #-}</span>
<span class="nf">tuple</span> <span class="ow">::</span> forall a<span class="o">.</span> a <span class="ow">-></span> <span class="p">(</span>forall b<span class="o">.</span> b <span class="ow">-></span> <span class="p">(</span>a<span class="p">,</span> b<span class="p">))</span>
<span class="nf">tuple</span> <span class="ow">=</span> <span class="p">(,)</span>
</pre></div><p>
The message is as follows:
</p>
<pre class="wiki">Main.hs:2:10:
Illegal polymorphic or qualified type: forall b. b -> (a, b)
Perhaps you intended to use -XRankNTypes or -XRank2Types
In the type signature for `tuple':
tuple :: forall a. a -> (forall b. b -> (a, b))
</pre><p>
As far as I know, the rank of a type is defined by how deep quantifiers are nested in contravariant parts of that type. Or something like that. Also, as far as I know, <tt>forall a. a -> (forall b. b -> (a, b))</tt> is equivalent to <tt>forall a b. a -> b -> (a, b)</tt>, and more importantly, both are rank-1 polymorphic. There should be no need to use extensions that allow higher-ranked polymorphism.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8346#changelog
http://ghc.haskell.org/trac/ghc/ticket/8387
http://ghc.haskell.org/trac/ghc/ticket/8387#8387: View patterns + pattern bindings: finnicky about scopingMon, 30 Sep 2013 14:01:33 GMTtinctorius<p>
Assume <tt>{-# LANGUAGE ViewPatterns #-}</tt>.
</p>
<p>
This works:
</p>
<pre class="wiki">(id -> ()) = ()
</pre><p>
This also works:
</p>
<pre class="wiki">di :: a -> a
di = \x -> x
where
(di -> ()) = ()
</pre><p>
But none of the following work:
</p>
<pre class="wiki">(di -> ()) = () -- Not in scope: di
di :: a -> a
di = \x -> x
</pre><pre class="wiki">di :: a -> a
di = \x -> x
(di -> ()) = () -- Not in scope: di
</pre><pre class="wiki">(di -> ()) = () -- Not in scope: di
where
di :: a -> a
di = \x -> x
</pre><p>
This looks like a bug to me. Is it? And is this in any way related to <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4061" title="feature request: Implement mutually recursive view patterns (closed: wontfix)">#4061</a>?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8387#changelog
http://ghc.haskell.org/trac/ghc/ticket/8422
http://ghc.haskell.org/trac/ghc/ticket/8422#8422: type nats solver is too weak!Tue, 08 Oct 2013 21:02:58 GMTcarter<p>
I just built ghc HEAD today, and the type nat solver can't handle the attached program, which *should* be simple to check! (and while I could use unsafeCoerce to "prove" it correct, that defeats the purpose of having the type nat solver!)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8422#changelog
http://ghc.haskell.org/trac/ghc/ticket/8524
http://ghc.haskell.org/trac/ghc/ticket/8524#8524: GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literalsTue, 12 Nov 2013 03:39:03 GMToerjan<p>
GHC is inconsistent with the Haskell Report on which Unicode characters are allowed in string and character literals. (And I don't like either option, why leave out any characters in strings unnecessarily?)
</p>
<p>
Examples from ghci 7.6.3 (also tested in lambdabot on irc):
</p>
<pre class="wiki">Prelude> "" -- Unicode char \8203, Format class.
<interactive>:10:2:
lexical error in string/character literal at character '\8203'
Prelude> " " -- Unicode char \8202, Space class.
"\8202"
Prelude> "t\ \est" -- Unicode char \8202 in a string gap.
<interactive>:14:4:
lexical error in string/character literal at character '\8202'
</pre><p>
My reading of <a class="ext-link" href="http://www.haskell.org/onlinereport/haskell2010/haskellch2.html"><span class="icon"></span>http://www.haskell.org/onlinereport/haskell2010/haskellch2.html</a>
(section 2.2 and 2.6):
</p>
<ul><li>The report BNF token "graphic", which can be used in literals, includes indirectly many Unicode classes, but uniWhite is not one of them. Thus the only Unicode whitespace allowed to represent itself in literals is ASCII space.
</li><li>Unicode formatting characters are not mentioned in the BNF that I can see, so are not allowed in literals.
</li><li>String gaps are made out of the report BNF token whitespace, which <em>does</em> include uniWhite.
</li></ul><p>
Who wants what:
</p>
<table class="wiki">
<tr><td style="text-align: center"> </td><th> GHC </th><th> Report </th><th> Me
</th></tr><tr><td> Format in string </td><td style="text-align: center"> No </td><td style="text-align: center"> No </td><td style="text-align: center"> Yes
</td></tr><tr><td> Space/uniWhite in string </td><td style="text-align: center"> Yes </td><td style="text-align: center"> No </td><td style="text-align: center"> Yes
</td></tr><tr><td> Space/uniWhite in string gap </td><td style="text-align: center"> No </td><td style="text-align: center"> Yes </td><td style="text-align: center"> Dunno
</td></tr></table>
<p>
In short, GHC's behavior is buggy and/or annoying in two opposite ways:
</p>
<ul><li>It leaves out some Unicode characters as allowable in strings and character literals, presumably because the report says so.
</li><li>It allows some characters the report says it <em>shouldn't</em>, and refuses some characters the report says it <em>should</em>.
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8524#changelog
http://ghc.haskell.org/trac/ghc/ticket/8555
http://ghc.haskell.org/trac/ghc/ticket/8555#8555: Simplify given `Coercible` constraintsFri, 22 Nov 2013 14:00:56 GMTnomeata<p>
It would be feasible and possibly useful if
</p>
<pre class="wiki">foo :: Coercible [a] [b] => a -> b
foo = coerce
</pre><p>
would work. This involve simplifying <tt>CtGiven</tt>s similar to how given (nominal) equalities are simplified.
</p>
<p>
I’ll defer working on this, as it is not strictly required, it seems.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8555#changelog
http://ghc.haskell.org/trac/ghc/ticket/8740
http://ghc.haskell.org/trac/ghc/ticket/8740#8740: Deriving instance conditionally compilesWed, 05 Feb 2014 20:44:03 GMTthomaseding<pre class="wiki">{-# LANGUAGE GADTs #-}
{-# LANGUAGE StandaloneDeriving #-}
data Abstract
data Reified
data Player
data Elect p a where
ElectRefAsTypeOf :: Int -> Elect Abstract a -> Elect Abstract a
ElectHandle :: a -> Elect Reified a
Controller :: Elect Abstract Player
Owner :: Elect Abstract Player
You :: Elect Abstract Player
deriving instance (Eq a) => Eq (Elect p a)
deriving instance (Ord a) => Ord (Elect p a)
</pre><p>
As is, the above code fails to compile. But if I move <tt>ElectRefAsTypeOf</tt> to be the last constructor for the GADT, the code does compile. If I remove one of the <tt>Elect Abstract Player</tt> constructors, the code still won't compile even if the <tt>ElectRefAsTypeOf</tt> is moved.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8740#changelog
http://ghc.haskell.org/trac/ghc/ticket/8808
http://ghc.haskell.org/trac/ghc/ticket/8808#8808: ImpredicativeTypes type checking fails depending on syntax of argumentsThu, 20 Feb 2014 05:40:52 GMTguest<p>
g1 and g2 below type check, but g1', g2', and g2<em> don't even though the types are exactly the same.
</em></p>
<pre class="wiki">{-# LANGUAGE ImpredicativeTypes, NoMonomorphismRestriction #-}
module Test where
f1 :: Maybe (forall a. [a] -> [a]) -> Maybe ([Int], [Char])
f1 (Just g) = Just (g [3], g "hello")
f1 Nothing = Nothing
f2 :: [forall a. [a] -> [a]] -> Maybe ([Int], [Char])
f2 [g] = Just (g [3], g "hello")
f2 [] = Nothing
g1 = (f1 . Just) reverse
g1' = f1 (Just reverse)
g2 = f2 [reverse]
g2' = f2 ((:[]) reverse)
g2'' = f2 (reverse : [])
</pre><p>
Compiling it with HEAD gives these errors:
</p>
<pre class="wiki">[1 of 1] Compiling Test ( test.hs, test.o )
test.hs:12:16:
Couldn't match expected type ‛forall a. [a] -> [a]’
with actual type ‛[a2] -> [a2]’
In the first argument of ‛Just’, namely ‛reverse’
In the first argument of ‛f1’, namely ‛(Just reverse)’
test.hs:15:17:
Couldn't match expected type ‛forall a. [a] -> [a]’
with actual type ‛[a0] -> [a0]’
In the first argument of ‛: []’, namely ‛reverse’
In the first argument of ‛f2’, namely ‛((: []) reverse)’
test.hs:16:12:
Couldn't match expected type ‛forall a. [a] -> [a]’
with actual type ‛[a1] -> [a1]’
In the first argument of ‛(:)’, namely ‛reverse’
In the first argument of ‛f2’, namely ‛(reverse : [])’
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8808#changelog
http://ghc.haskell.org/trac/ghc/ticket/8926
http://ghc.haskell.org/trac/ghc/ticket/8926#8926: GHC makes unsound references in object codeMon, 24 Mar 2014 23:12:50 GMTanton.dubovik<p>
To reproduce the bug run script <tt>run.sh</tt> from the attached archive.
</p>
<p>
It will:
</p>
<ol><li>install <tt>FooPackage</tt>
</li></ol><pre class="wiki">Resolving dependencies...
Configuring FooPackage-0.1...
Building FooPackage-0.1...
Preprocessing library FooPackage-0.1...
[1 of 1] Compiling FooPackage ( src\FooPackage.hs, dist\build\FooPackage.o )
In-place registering FooPackage-0.1...
Installing library in
C:\Users\Anton\AppData\Roaming\cabal\i386-windows-ghc-7.6.3\FooPackage-0.1
Registering FooPackage-0.1...
Installed FooPackage-0.1
</pre><ol start="2"><li>compile executable <tt>Client1</tt> which depends on <tt>FooPackage</tt>
</li></ol><pre class="wiki">[1 of 3] Compiling QuxClient ( QuxClient.hs, obj\QuxClient.o )
[2 of 3] Compiling BarClient ( BarClient.hs, obj\BarClient.o )
[3 of 3] Compiling Client1 ( Client1.hs, obj\Client1.o )
Linking exes/Client1.exe ...
</pre><ol start="3"><li>compile executable <tt>Client2</tt> which doesn't depend on <tt>FooPackage</tt>
</li></ol><blockquote>
<p>
At the third step GHC will fall with linker error:
</p>
</blockquote>
<pre class="wiki">[2 of 2] Compiling Client2 ( Client2.hs, obj\Client2.o )
Linking exes/Client2.exe ...
obj\BarClient.o:fake:(.text+0x83): undefined reference to `FooPackagezm0zi1_FooPackage_zdsinsertzuzdsgo5_info'
obj\BarClient.o:fake:(.data+0x10): undefined reference to `FooPackagezm0zi1_FooPackage_zdsinsertzuzdsgo5_closure'
collect2: ld returned 1 exit status
</pre><p>
Both <tt>Client1</tt> and <tt>Client2</tt> import <tt>BarClient</tt> module that doesn't depends on <tt>FooPackage</tt>.
<tt>Client1</tt> imports <tt>QuxClient</tt> that imports <tt>FooPackage</tt>:
</p>
<pre class="wiki">module QuxClient where
import FooPackage(foo)
import Data.Set
qux :: Set String -> Set String
qux = foo
</pre><pre class="wiki">module BarClient where
import Data.Set
bar :: Set String -> Set String
bar s = insert "bar" s
</pre><p>
<tt>FooPackage</tt> uses function <tt>Data.Set.insert</tt> which is marked at <tt>Data.Set</tt> as <tt>INLINABLE</tt>:
</p>
<pre class="wiki">module FooPackage where
import Data.Set
foo :: Set String -> Set String
foo s = insert "foo" s
</pre><p>
GHC emphasizes in interface file, that <tt>FooPackage.o</tt> contains specialized version of <tt>Data.Set.insert</tt>:
</p>
<pre class="wiki">> ghc --show-iface FooPackage.hi
...
"SPEC Data.Set.Base.insert [GHC.Base.String]" [ALWAYS] forall $dOrd :: GHC.Classes.Ord
GHC.Base.String
Data.Set.Base.insert @ [GHC.Types.Char] $dOrd = FooPackage.$sinsert
...
</pre><p>
Later GHC see again the use of <tt>Data.Set.insert@String</tt> at <tt>BarClient</tt> and decides to apply this specialise rule, so that <tt>BarClient</tt> now has reference to <tt>FooPackage</tt>:
</p>
<pre class="wiki">> ghc --show-iface BarClient.hi
...
bar :: Data.Set.Base.Set GHC.Base.String
-> Data.Set.Base.Set GHC.Base.String
{- Arity: 1, Strictness: S,
Unfolding: (\ s :: Data.Set.Base.Set GHC.Base.String ->
FooPackage.$sinsert_$sgo5 BarClient.bar1 s) -}
...
</pre><p>
<tt>Client2</tt> doesn't depend on <tt>FooPackage</tt>, thus linker throws an error.
</p>
<p>
There are plenty of workarounds here, but all of them are ad hoc (1,2,3) or could affect performance (4):
</p>
<ol><li>Change the order of <tt>BarClient</tt> and <tt>QuxClient</tt> imports in <tt>Client1</tt> module.
</li><li>Compile <tt>Client1</tt> and <tt>Client2</tt> in opposite order.
</li><li>Add fake import at <tt>Client2</tt> module:
<pre class="wiki">import FooPackage()
</pre></li><li>Build <tt>FooPackage</tt> with ghc-option <tt>-fomit-interface-pragmas</tt>. That will eraise from <tt>FooPackage.hi</tt> all specialisation rules as well as information about strictness and inlining.
</li></ol><p>
Some information about the environment:
</p>
<pre class="wiki">> ghc-pkg list
...
containers-0.5.0.0
base-4.6.0.1
...
> ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.6.3
> cabal --version
cabal-install version 1.18.0.3
using version 1.18.1.3 of the Cabal library
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8926#changelog
http://ghc.haskell.org/trac/ghc/ticket/8947
http://ghc.haskell.org/trac/ghc/ticket/8947#8947: Depending on hint/ghc API fixes the binary version I can useWed, 02 Apr 2014 02:20:33 GMTnh2<p>
When I <tt>build-depend</tt> on hint-0.4.0.0 with GHC 7.6.3, I get
</p>
<pre class="wiki">% cabal configure
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: pointcloudviewer-0.1.0 (user goal)
trying: hint-0.4.0.0/installed-cf3... (dependency of pointcloudviewer-0.1.0)
trying: ghc-7.6.3/installed-494... (dependency of
hint-0.4.0.0/installed-cf3...)
trying: bin-package-db-0.0.0.0/installed-608... (dependency of
ghc-7.6.3/installed-494...)
trying: GLUtil-0.7.4/installed-223... (dependency of pointcloudviewer-0.1.0)
next goal: linear (dependency of GLUtil-0.7.4/installed-223...)
rejecting: linear-1.6/installed-300... (conflict: bin-package-db =>
binary==0.5.1.1/installed-72e..., linear => binary==0.7.1.0/installed-a33...)
</pre><p>
This fails because <tt>linear</tt> uses a <tt>binary > 0.5.1.1</tt>, but through my use of <tt>hint</tt> which depends on <tt>ghc</tt> (<tt>hint</tt> does not directly depend on <tt>binary</tt>), I pull in a constraint <tt>binary == 0.5.1.1</tt>.
</p>
<p>
I believe this is bad, because depending on the GHC API in any way fixes the binary version I can use, which immediately makes a range of newer libraries unavailable to my program.
</p>
<p>
Probably GHC should somehow hide the fact that binary is used inside, and let the rest of my program use whatever binary it likes.
</p>
<hr />
<p>
I am aware that this might not be immediately easy, since the GHC API might expose some <tt>binary</tt> types to my program that I could try use with my newer binary version, which of course would be illegal.
</p>
<p>
Maybe it is possible to implement such a check into actual typechecking, and let it pass if I don't actually use types from the old version with functions from the new library. I actually believe I have seen compiler errors in the past where two identical types where not unified because one was from a different version, so maybe infrastructure for this is already in place?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8947#changelog
http://ghc.haskell.org/trac/ghc/ticket/8966
http://ghc.haskell.org/trac/ghc/ticket/8966#8966: Pattern synonyms and kind-polymorphismMon, 07 Apr 2014 12:59:03 GMTkosmikus<p>
There's a strange interaction between pattern synonyms, GADTs, kind polymorphism and data kinds.
</p>
<p>
The following module fails to compile with ghc-7.8.1-rc2, but I think it should:
</p>
<pre class="wiki">{-# LANGUAGE PolyKinds, KindSignatures, PatternSynonyms, DataKinds, GADTs #-}
data NQ :: [k] -> * where
D :: NQ '[a]
pattern Q = D
</pre><p>
I get the following error:
</p>
<pre class="wiki">KindPat.hs:6:13:
Could not deduce (a ~ a0)
from the context (t ~ '[a])
bound by the type signature for (Main.$WQ) :: t ~ '[a] => NQ t
at KindPat.hs:6:9
‘a’ is a rigid type variable bound by
the type signature for (Main.$WQ) :: t ~ '[a] => NQ t
at KindPat.hs:6:13
Expected type: NQ t
Actual type: NQ '[a0]
In the expression: D
In an equation for ‘$WQ’: ($WQ) = D
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8966#changelog
http://ghc.haskell.org/trac/ghc/ticket/8968
http://ghc.haskell.org/trac/ghc/ticket/8968#8968: Pattern synonyms and GADTsMon, 07 Apr 2014 15:36:35 GMTkosmikus<p>
I think this one is different from <a class="merge ticket" href="http://ghc.haskell.org/trac/ghc/ticket/8966" title="bug: Pattern synonyms and kind-polymorphism (merge)">#8966</a>, but feel free to close one as duplicate if it turns out to be the same problem.
</p>
<p>
The following program (using GADTs and pattern synonyms, but not kind polymorphism or data kinds) fails to check with ghc-7.8.1-rc2, but I think it should:
</p>
<pre class="wiki">{-# LANGUAGE GADTs, KindSignatures, PatternSynonyms #-}
data X :: (* -> *) -> * -> * where
Y :: f Int -> X f Int
pattern C x = Y (Just x)
</pre><p>
The error I get is the following:
</p>
<pre class="wiki">PatKind.hs:6:18:
Couldn't match type ‘t’ with ‘Maybe’
‘t’ is untouchable
inside the constraints (t1 ~ Int)
bound by a pattern with constructor
Y :: forall (f :: * -> *). f Int -> X f Int,
in a pattern synonym declaration
at PatKind.hs:6:15-24
‘t’ is a rigid type variable bound by
the inferred type of
C :: X t t1
x :: Int
at PatKind.hs:1:1
Expected type: t Int
Actual type: Maybe Int
In the pattern: Just x
In the pattern: Y (Just x)
PatKind.hs:6:18:
Could not deduce (t ~ Maybe)
from the context (t1 ~ Int)
bound by the type signature for
(Main.$WC) :: t1 ~ Int => Int -> X t t1
at PatKind.hs:6:9
‘t’ is a rigid type variable bound by
the type signature for (Main.$WC) :: t1 ~ Int => Int -> X t t1
at PatKind.hs:1:1
Expected type: t Int
Actual type: Maybe Int
Relevant bindings include
($WC) :: Int -> X t t1 (bound at PatKind.hs:6:9)
In the first argument of ‘Y’, namely ‘(Just x)’
In the expression: Y (Just x)
</pre><p>
Note that I'd be perfectly happy to provide a type signature for the pattern synonym, but I don't know of any syntax I could use. The Wiki page at <a class="ext-link" href="https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms"><span class="icon"></span>https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms</a> mentions I might be able to write
</p>
<pre class="wiki">pattern C :: Int -> X Maybe Int
</pre><p>
but this triggers a parse error.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8968#changelog
http://ghc.haskell.org/trac/ghc/ticket/8985
http://ghc.haskell.org/trac/ghc/ticket/8985#8985: Strange kind error with type family, GADTs, data kinds, and kind polymorphismFri, 11 Apr 2014 07:16:52 GMTkosmikus<p>
Consider the following test case (I've tried hard to make it minimal, which unfortunately means there's not a lot of intuition left):
</p>
<pre class="wiki">{-# LANGUAGE DataKinds, PolyKinds, TypeFamilies, GADTs, TypeOperators #-}
data X (xs :: [k]) = MkX
data Y :: (k -> *) -> [k] -> * where
MkY :: f x -> Y f (x ': xs)
type family F (a :: [[*]]) :: *
type instance F xss = Y X xss
works :: Y X '[ '[ ] ] -> ()
works (MkY MkX) = ()
fails :: F '[ '[ ] ] -> ()
fails (MkY MkX) = ()
</pre><p>
This code compiles in GHC 7.6.3, but it fails in GHC 7.8.1 (both rc2 and the actual release) with the following error:
</p>
<pre class="wiki">TestCase.hs:14:8:
Couldn't match kind ‘k0’ with ‘*’
Expected type: F '['[]]
Actual type: Y t0 t1
In the pattern: MkY MkX
In an equation for ‘fails’: fails (MkY MkX) = ()
TestCase.hs:14:12:
Couldn't match type ‘t0’ with ‘X’
‘t0’ is untouchable
inside the constraints (t1 ~ (x : xs))
bound by a pattern with constructor
MkY :: forall (f :: k -> *) (x :: k) (xs :: [k]).
f x -> Y f (x : xs),
in an equation for ‘fails’
at TestCase.hs:14:8-14
Expected type: t0 x
Actual type: X x
In the pattern: MkX
In the pattern: MkY MkX
In an equation for ‘fails’: fails (MkY MkX) = ()
</pre><p>
I'm puzzled that simply adding the type family invokation makes the type checker fail with a kind error, even though the type family itself itsn't kind-polymorphic.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8985#changelog
http://ghc.haskell.org/trac/ghc/ticket/345
http://ghc.haskell.org/trac/ghc/ticket/345#345: GADT - fundep interactionFri, 08 Apr 2005 10:02:38 GMTbring<pre class="wiki">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)
-}
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/345#changelog
http://ghc.haskell.org/trac/ghc/ticket/3766
http://ghc.haskell.org/trac/ghc/ticket/3766#3766: Parsing of lambdas is not consistent with Haskell'98 report.Wed, 16 Dec 2009 16:05:09 GMTlilac<p>
Consider the following expression:
</p>
<p>
<tt> (\x -> x :: Int . id)</tt>
</p>
<p>
GHC (without any -X flags) currently reports a parse error:
</p>
<blockquote>
<p>
Illegal operator <tt>.' in type </tt>Int . id'<br /> Use -XTypeOperators to allow operators in types
</p>
</blockquote>
<p>
However, I think this expression is legal in Haskell'98 (and indeed still legal in Haskell 2010). The report gives an (ambiguous) expression grammar, which (unambiguously) parses the above as (\x -> (x :: Int)) . id. The report further says that lambdas extend as far as possible to the right, but the parse which GHC is using is not a possible parse according to the grammar, since infix operators (other than "->") are not allowed in the construction 'type'.
</p>
<p>
That said, I'd much rather see this fixed in the Haskell 2011 report than in GHC :)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3766#changelog
http://ghc.haskell.org/trac/ghc/ticket/4836
http://ghc.haskell.org/trac/ghc/ticket/4836#4836: literate markdown not handled correctly by unlitSun, 12 Dec 2010 19:22:52 GMTguest<p>
This simple program in literate haskell, using markdown in the comments gives unlit problems:
</p>
<pre class="wiki">### 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!
</pre><p>
If I run unlit and collect the output I can see where it went wrong:
</p>
<pre class="wiki">$ ~/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
</pre><p>
When I look through the source code of unlit.c I think the place to check for this would be here:
</p>
<pre class="wiki"> 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;
}
}
</pre><p>
It seems that cabal has a similar unlit function:
<a href="http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal-1.10.0.0/src/Distribution-Simple-PreProcess-Unlit.html#unlit">http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal-1.10.0.0/src/Distribution-Simple-PreProcess-Unlit.html#unlit</a>
</p>
<p>
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?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4836#changelog
http://ghc.haskell.org/trac/ghc/ticket/4899
http://ghc.haskell.org/trac/ghc/ticket/4899#4899: Non-standard compile plus Template Haskell produces spurious "unknown symbol" linker errorTue, 18 Jan 2011 00:44:27 GMTjepst<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4899#changelog
http://ghc.haskell.org/trac/ghc/ticket/5248
http://ghc.haskell.org/trac/ghc/ticket/5248#5248: Infer type context in a type signatureThu, 09 Jun 2011 19:02:22 GMTgidyn<p>
If I have code such as
</p>
<pre class="wiki">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)
</pre><p>
GHC will demand <tt>Foo f =></tt> on the instance declaration, even though this can be inferred from the definition of Bar.
</p>
<p>
I understand <em>why</em> 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.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5248#changelog
http://ghc.haskell.org/trac/ghc/ticket/5296
http://ghc.haskell.org/trac/ghc/ticket/5296#5296: Add explicit type applicationsSun, 03 Jul 2011 17:30:35 GMTdsf<p>
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.
</p>
<pre class="wiki">{-# 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
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/5296#changelog
http://ghc.haskell.org/trac/ghc/ticket/5316
http://ghc.haskell.org/trac/ghc/ticket/5316#5316: Orphan instances strike again: ghc rejects a program at first but will accept it if you repeat the same compilation commandMon, 11 Jul 2011 20:24:10 GMTjcpetruzza<p>
Consider these two modules (boiled down example from the checkers package):
</p>
<pre class="wiki">{-# 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)
</pre><pre class="wiki">module T2 where
import Control.Concurrent
g = threadDelay maxBound
</pre><p>
I see the following interaction:
</p>
<pre class="wiki">$ 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
</pre><p>
I see this consistent behaviour in versions 7.0.{1,2,3,4} but not with 6.12.1
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5316#changelog
http://ghc.haskell.org/trac/ghc/ticket/5333
http://ghc.haskell.org/trac/ghc/ticket/5333#5333: Arrow command combinators and infixr cause the desugarer to failWed, 20 Jul 2011 01:46:52 GMTpeteg<p>
The following code exhibits the bug:
</p>
<pre class="wiki">{-# 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))
</pre><p>
GHC says:
</p>
<pre class="wiki">ghc: panic! (the 'impossible' happened)
(GHC version 7.0.3 for i386-apple-darwin):
dsSyntaxTable Not found: base:GHC.Desugar.>>>{v 01W}
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/5333#changelog
http://ghc.haskell.org/trac/ghc/ticket/6034
http://ghc.haskell.org/trac/ghc/ticket/6034#6034: Parse error when using ' with promoted kindsMon, 23 Apr 2012 15:48:30 GMTgoldfire<p>
The following code generates a parse error:
</p>
<pre class="wiki">{-# LANGUAGE DataKinds #-}
data Proxy a = Proxy
foo :: Proxy '['[True, False],'[False]]
foo = Proxy
</pre><p>
The problem is that the <tt>'['</tt> prefix to the type index is parsed as a character. Rewriting that string as <tt>'[ '</tt> fixes the problem.
</p>
<p>
This is admittedly a very low priority problem, but it seemed to be enough of an infelicity to be worth reporting.
</p>
<p>
This was tested on 7.5.20120420.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/6034#changelog
http://ghc.haskell.org/trac/ghc/ticket/8161
http://ghc.haskell.org/trac/ghc/ticket/8161#8161: Associated type parameters that are more specific than the instance headerFri, 23 Aug 2013 12:45:59 GMTadamgundry<p>
It would be nice if type parameters of associated types could be more specific than those in the instance header. This is currently rejected with the message "Type indexes must match class instance head", but could be accepted:
</p>
<pre class="wiki">{-# LANGUAGE TypeFamilies #-}
class C a where
type T a
instance C [a] where
type T [Bool] = Int
type T [Int] = Int
</pre><p>
More typically, this is useful where we want to use an equality constraint to make type inference easier, but need to match on the actual type in an associated type:
</p>
<pre class="wiki">{-# LANGUAGE TypeFamilies, FlexibleInstances #-}
class C a where
type T a
instance a ~ [b] => C a where
type T [b] = Int
</pre><p>
This showed up in the implementation of <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan">OverloadedRecordFields</a>. Of course, one can always work around it using a normal (non-associated) type family.
</p>
<p>
Note that we already allow type families to specialise variables that do not occur in the instance header:
</p>
<pre class="wiki">{-# LANGUAGE TypeFamilies #-}
class C a where
type T a b
instance C [a] where
type T [a] [Bool] = Bool
type T [a] [Int] = Int
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8161#changelog
http://ghc.haskell.org/trac/ghc/ticket/8447
http://ghc.haskell.org/trac/ghc/ticket/8447#8447: A combination of type-level comparison and subtraction does not work for 0Tue, 15 Oct 2013 06:19:42 GMTnushio<p>
The following function on type level naturals
</p>
<pre class="wiki"> Diff x y = If (x <=? y) (y-x) (x-y)
</pre><p>
does not work when either x or y is 0.
</p>
<p>
<a class="ext-link" href="https://github.com/nushio3/practice/blob/ea8a1716b1d6221ce32d77432b6de3f38e653a27/type-nats/int-bug.hs"><span class="icon"></span>https://github.com/nushio3/practice/blob/ea8a1716b1d6221ce32d77432b6de3f38e653a27/type-nats/int-bug.hs</a>
</p>
<p>
I've tested this code on ghc 7.7.20130926 since I couldn't build the really latest ghc. I'm sorry if it is already fixed on the ghc head.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8447#changelog
http://ghc.haskell.org/trac/ghc/ticket/860
http://ghc.haskell.org/trac/ghc/ticket/860#860: CPP fails when a macro is used on a line containing a single quote characterThu, 10 Aug 2006 10:18:02 GMTketil@…<p>
CPP is nice when you need a quick-and-dirty solution, but one little stumbling block is
that macros are not expanded when the line contains a single quote character (as in function names ending in "prime" - let x' = MACRO x in...).
</p>
<p>
One solution is of course to break the line between the macro and the quote, but it'd be nice to have a CPP that was just a <em>bit</em> more clever.
</p>
<p>
-k
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/860#changelog