GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?status=!closed&priority=highest&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&priority=highest&order=priority
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/4426
http://ghc.haskell.org/trac/ghc/ticket/4426#4426: Simplify the rules for implicit quantificationFri, 22 Oct 2010 08:19:18 GMTsimonpj<p>
This thread <a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-users/2010-October/019360.html"><span class="icon"></span>http://www.haskell.org/pipermail/glasgow-haskell-users/2010-October/019360.html</a>
convinced me that GHC's rules for implicit quantification are unnecessarily complicated.
</p>
<hr />
<h2 id="Thecurrentspec">The current spec</h2>
<p>
The current spec seems to be this:
</p>
<ul><li>Define an "implicit quantification point" to be (a) the type in a type signature <tt>f :: type</tt> if <tt>type</tt> does not start with <tt>forall</tt>; or (b) a type of form <tt>(context => type)</tt>, that is not immediately enclosed by an explicit <tt>forall</tt>
</li></ul><ul><li>At each implicit quantification point 'ty', working outside in, GHC finds all the type variables a,b,c in 'ty' that are not already in scope, and transforms 'ty' to (forall a,b,c. ty).
</li></ul><p>
Note that
</p>
<ul><li>The argument of a constructor is not an implicit quantification point, so that
<pre class="wiki">data Foo = MkFoo (a -> a)
</pre>is an error, and does not mean
<pre class="wiki">data Foo = MkFoo (forall a. a->a)
</pre></li></ul><ul><li>Implicit quantification points may be nested but the inner ones are effectively no-ops. Example
<pre class="wiki">f :: Int -> (Eq a => a -> a) -> Int
</pre>There are two quantification points: the whole type, and the <tt>(Eq a => ...)</tt>. But when the outer quantification point wraps forall a around it, the inner quantification point has no free variables to quantify. So we get
<pre class="wiki">f :: forall a. Int -> (Eq a => a -> a) -> Int
</pre></li></ul><hr />
<h2 id="Thenewproposal">The new proposal</h2>
<p>
The proposed new rule is this:
</p>
<ul><li>Implicit quantification applies only to an entire user type signature that does not start with <tt>forall</tt>.
</li><li>For such signatures, find all the type variables a,b,c in the signature that are not already in scope, and prefix the signature with <tt>forall a,b,c.</tt>
</li></ul><p>
I believe that the only observable changes in behaviour would be
</p>
<ul><li>In a data type declaration
<pre class="wiki">data Foo = MkFoo (Eq a => a -> a)
</pre>you'd get an error "a is not in scope", just as you would with
<pre class="wiki">data Foo = MkFoo (a->a)
</pre>To me this seems more consistent behavour.
</li></ul><ul><li>Inside an <em>explicit</em> <tt>forall</tt> you would get no <em>implicit</em> <tt>foralls</tt>:
<pre class="wiki">f :: forall a. (Eq b => b->b) -> a -> a
</pre>would yield "b is not in scope", whereas at present it behaves like
<pre class="wiki">f :: forall a. (forall b. Eq b => b->b) -> a -> a
</pre></li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/4426#changelog
http://ghc.haskell.org/trac/ghc/ticket/8330
http://ghc.haskell.org/trac/ghc/ticket/8330#8330: Remove ExtsCompat46 module once we bootstrap with GHC 7.8Thu, 19 Sep 2013 10:30:41 GMTjstolarek<p>
Changing type signature of comparison primops from <tt>Bool</tt> to <tt>Int#</tt> in GHC 7.8 (see <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/6135" title="feature request: Unboxed Booleans (closed: fixed)">#6135</a>) caused a problem: type signatures of functions might be different for the bootstrapping compiler (if it is older than 7.8) than they are for the stage1 compiler. In order to solve this problem I introduced a compatibility module <a href="/trac/ghc/browser/ghc/compiler/utils/ExtsCompat46">compiler/utils/ExtsCompat46</a> that provides different definition of primops for older versions of GHC (<tt>__GLASGOW_HASKELL__ <= 706</tt>) and different for newer versions (<tt>__GLASGOW_HASKELL__ > 706</tt>). However, once we set minimal version of GHC required for bootstrapping to be 7.8, we can (and should!) remove that compatibility module and go back to using GHC.Exts. This ticket is a reminder that we should do this after we release GHC 7.10 or 7.12.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8330#changelog
http://ghc.haskell.org/trac/ghc/ticket/9439
http://ghc.haskell.org/trac/ghc/ticket/9439#9439: LlvmCodegen: Overzealous mangler incorrectly transforms user codeThu, 14 Aug 2014 04:20:58 GMTbgamari<p>
In an attempt to close <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4210" title="feature request: LLVM: Dynamic Library Support (closed: fixed)">#4210</a> the LLVM code generator's mangler was modified in
<a class="changeset" href="http://ghc.haskell.org/trac/ghc/changeset/ed67d290e7389bd87a6feea269a0275e0f0f5e2f/ghc" title="LlvmMangler: Rewrite @function symbols to @object
Signed-off-by: Austin ...">ed67d290e7389bd87a6feea269a0275e0f0f5e2f</a> to rewrite symbol types from <tt>@function</tt> to <tt>@object</tt>. This was done in order to prevent the linker from sending reference through the PLT which breaks info tables.
</p>
<p>
Unfortunately, this mangling was a simple text replacement of <tt>@function</tt> to <tt>@object</tt> in the assembler produced by LLVM and made no attempt to distinguish <tt>.type</tt> directives (which the mangling targets) from other occurrences of the token. As rwbarton unfortunately found out, this means that any occurrences of <tt>"@function"</tt> in user code (e.g. the LLVM backend itself while compiling GHC) will be rewritten to <tt>"@object"</tt> in the produced object. Hilarity ensues.
</p>
<p>
This can be demonstrated by the simple test <tt>main = putStrLn "@function"</tt>, which prints <tt>@object</tt> in the affected releases (7.8.1 through 7.8.3 thusfar).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9439#changelog
http://ghc.haskell.org/trac/ghc/ticket/9858
http://ghc.haskell.org/trac/ghc/ticket/9858#9858: Typeable instances should be kind-awareWed, 03 Dec 2014 16:27:56 GMTdreixel<pre class="wiki">{-# LANGUAGE DataKinds #-}
{-# LANGUAGE AutoDeriveTypeable #-}
import Data.Typeable
data A = A
main = print $ typeRep (Proxy :: Proxy A) == typeRep (Proxy :: Proxy 'A)
</pre><p>
This returns <tt>True</tt>, but it should return <tt>False</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/9858#changelog
http://ghc.haskell.org/trac/ghc/ticket/10058
http://ghc.haskell.org/trac/ghc/ticket/10058#10058: Panic: Loading temp shared object failedSun, 01 Feb 2015 18:55:25 GMTgoldfire<p>
I ran into a panic when updating <tt>singletons</tt> for 7.10. I'm clueless as to what's going on here, so sorry for not minimizing the test case. A little testing has me convinced it's Template Haskell in some way.
</p>
<p>
To reproduce:
</p>
<pre class="wiki">> git clone http://github.com/goldfirere/singletons.git
> cd singletons
> git checkout ghc-loading-panic-test-case
> cabal update
> cabal install --only-dependencies
> cabal configure
> cabal build
> cat dist/build/autogen/cabal_macros.h
# copy the value for CURRENT_PACKAGE_KEY from the end of cabal_macros.h
> cd tests/compile-and-dump
> ghc -c -this-package-key <package key from cabal_macros.h> -i../../dist/build -XTemplateHaskell Singletons/Maybe.hs
</pre><p>
You will see something like
</p>
<pre class="wiki">ghc: panic! (the 'impossible' happened)
(GHC version 7.10.0.20150123 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib, 5): Symbol not found: _mtlzuJNaGzzEkFfL43R3LZZNRlPRm_ControlziMonadziReaderziClass_DZCMonadReader_con_info
Referenced from: /var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib
Expected in: flat namespace
in /var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
</pre><p>
I've observed this on a Mac, but Travis has the same problem, so it's not strictly Mac-specific. You can see representative Travis output <a class="ext-link" href="https://travis-ci.org/goldfirere/singletons/jobs/49103793"><span class="icon"></span>here</a>.
</p>
<p>
Why am I doing such a crazy thing? It's part of the <tt>singletons</tt> test suite, where it's important to test the output of a run of ghc with <tt>-ddump-splices</tt>. Getting the test cases to compile against the built-but-not-yet-installed <tt>singletons</tt> object files should work with <tt>-this-package-key</tt>. I'm sure there's a better way to structure a testsuite, but this general technique works (with <tt>-package-name</tt> instead of <tt>-this-package-key</tt>) with 7.8.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/10058#changelog
http://ghc.haskell.org/trac/ghc/ticket/10099
http://ghc.haskell.org/trac/ghc/ticket/10099#10099: cabal install broken with ghc 7.10.1-rc2Wed, 18 Feb 2015 16:06:42 GMTtrommler<p>
Trying to install a package with cabal-install and Cabal from ghc 7.10-rc2
consistently gives this error message (<tt>primitive</tt> is just an example):
</p>
<pre class="wiki">peter@montebre:~> cabal install primitive
Resolving dependencies...
Configuring primitive-0.5.4.0...
cabal: Distribution/Client/Config.hs:(246,37)-(299,9): Missing field in record construction configProf
</pre><p>
This is my package database:
</p>
<pre class="wiki">peter@montebre:~> ghc-pkg list
/usr/lib64/ghc-7.10.0.20150123/package.conf.d
Cabal-1.22.1.0
HTTP-4000.2.19
array-0.5.0.1
base-4.8.0.0
bin-package-db-0.0.0.0
binary-0.7.3.0
bytestring-0.10.6.0
containers-0.5.6.2
deepseq-1.4.0.0
directory-1.2.2.0
filepath-1.3.1.0
ghc-7.10.0.20150123
ghc-prim-0.3.1.0
haskeline-0.7.2.0
hoopl-3.10.0.2
hpc-0.6.0.2
integer-gmp-1.0.0.0
mtl-2.2.1
network-2.4.2.3
old-locale-1.0.0.7
old-time-1.1.0.3
parsec-3.1.8
pretty-1.1.2.0
process-1.2.2.0
random-1.0.1.1
rts-1.0
stm-2.4.2
syb-0.4.4
template-haskell-2.10.0.0
terminfo-0.4.0.1
text-1.2.0.4
th-desugar-1.5
th-lift-0.7
time-1.5.0.1
transformers-0.4.2.0
unix-2.7.1.0
xhtml-3000.2.1
zlib-0.5.4.2
</pre><p>
I updated only those packages (from their versions in Haskell Platform) that would not compile with 7.101-rc2.
</p>
<p>
I am setting this to highest as this issue would be very annoying for everyone.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/10099#changelog
http://ghc.haskell.org/trac/ghc/ticket/10113
http://ghc.haskell.org/trac/ghc/ticket/10113#10113: Re-export (<$>) from PreludeTue, 24 Feb 2015 15:52:36 GMThvr<p>
See <a class="ext-link" href="http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161"><span class="icon"></span>http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161</a> for details
</p>
<p>
decision is still outstanding, but this needs to go into RC3 unless there's good reasons not to
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/10113#changelog
http://ghc.haskell.org/trac/ghc/ticket/10115
http://ghc.haskell.org/trac/ghc/ticket/10115#10115: Unable to run cabal haddock --hoogle on GHC 7.10Wed, 25 Feb 2015 10:25:42 GMTsnoyberg<p>
At Herbert's recommendation, creating an issue based on the following email I sent to ghc-dev:
</p>
<p>
I'm not really able to follow the details of this, but I wanted to raise to everyone's attention a serious bug with the current GHC 7.10 RC, Cabal 1.22, and/or Haddock. Currently, running <tt>cabal haddock --hoogle</tt> does not work. There seem to be two different issues open about it:
</p>
<p>
<a class="ext-link" href="https://github.com/haskell/haddock/issues/361"><span class="icon"></span>https://github.com/haskell/haddock/issues/361</a>
<a class="ext-link" href="https://github.com/haskell/cabal/issues/2297"><span class="icon"></span>https://github.com/haskell/cabal/issues/2297</a>
</p>
<p>
I really don't understand the issues here, but I'd claim that the severity of this should probably be a blocker for a GHC 7.10 release.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/10115#changelog