GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&group=architecture&desc=1&order=milestone
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&group=architecture&desc=1&order=milestone
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/10024
http://ghc.haskell.org/trac/ghc/ticket/10024#10024: This bug tracker: Can not create filter `x contains y && x contains z`Mon, 26 Jan 2015 19:58:08 GMTlspitzner<p>
To Reproduce:
</p>
<ul><li>Start ticket search
</li><li>Create filter "description" and set phrase to "foo"
</li><li>Click the button "And" again, choose "description", set phrase to "bar"
</li><li>The filter now is set to <tt>description contains foo || description contains bar</tt>, instead of the expected <tt>s/||/&&/</tt>.
</li></ul><p>
Note that setting phrase to "foo bar" seems to search for "foo bar", not <tt>fold (||) . words</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/10024#changelog
http://ghc.haskell.org/trac/ghc/ticket/1487
http://ghc.haskell.org/trac/ghc/ticket/1487#1487: unix package: test needed for getLoginNameTue, 03 Jul 2007 10:51:27 GMTsimonmar<p>
I disabled the test for <tt>getLoginName</tt> in unix/tests/user001 because <tt>getLoginName</tt> cannot be called unless stdin is a terminal, which it isn't during an unattended build. Perhaps we can test this by setting up a pseudoterminal first, but that requires the pty patches which aren't in yet.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1487#changelog
http://ghc.haskell.org/trac/ghc/ticket/2595
http://ghc.haskell.org/trac/ghc/ticket/2595#2595: Implement record update for existential and GADT data typesMon, 15 Sep 2008 14:00:45 GMTsimonpj<p>
Ganesh writes: The most important thing for me is supporting record update for
existentially quantified data records, as in the error below.
</p>
<p>
In general I also find working with code that involves existential
type variables quite hard work - for example I can't use foo as a
record selector either, even if I immediately do something that seals
the existential type back up again.
</p>
<p>
I don't understand this stuff well enough to be sure whether it's an
impredicativity issue or not, though.
</p>
<pre class="wiki">Foo.hs:11:8:
Record update for the non-Haskell-98 data type `Foo' is not (yet)
supported
Use pattern-matching instead
In the expression: rec {foo = id}
In the definition of `f': f rec = rec {foo = id}
</pre><p>
Program is:
</p>
<pre class="wiki">{-# LANGUAGE Rank2Types #-}
module Foo where
data Foo = forall a . Foo { foo :: a -> a, bar :: Int }
x :: Foo
x = Foo { foo = id, bar = 3 }
f :: Foo -> Foo
f rec = rec { foo = id }
g :: Foo -> Foo
g rec = rec { bar = 3 }
</pre><p>
Simon says: Ah now I see. The relevant comment, <tt>TcExpr</tt> line 465, says
</p>
<pre class="wiki">-- Doing record updates on
-- GADTs and/or existentials is more than my tiny
-- brain can cope with today
</pre><p>
Should be fixable, even with a tiny brain.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2595#changelog
http://ghc.haskell.org/trac/ghc/ticket/3517
http://ghc.haskell.org/trac/ghc/ticket/3517#3517: GHC has lots of extra hidden IOErrorType valuesTue, 15 Sep 2009 23:55:01 GMTduncan<p>
I was fixing bytestring's hGet (see <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3514" title="merge: mallocPlainForeignPtrBytes -1000 gives runtime internal error: allocGroup: ... (closed: fixed)">#3514</a>) and I discover that I cannot produce the same exception as System.IO.hGet does in the same circumstance.
</p>
<p>
There are two problems:
</p>
<p>
One is that GHC's internal IOError has more information than one can set via System.IO.Error.mkIOError. In particular it has a function name.
</p>
<p>
The other is that System.IO.hGet throws an <tt>InvalidArgument</tt> <tt>IOErrorType</tt>, however this is not exported and there are no smart constructors or testers for this error type. This is problematic for two reasons, portable code cannot generate these error types to mirror the standard System.IO and secondly no code can actually catch these errors except in a general "catch all" style because they cannot be distinguished from each other.
</p>
<p>
Code that wants to mirror System.IO (like bytestring or utf8-string) has to import GHC.IO.Exception and use cpp to do it differently for hugs and nhc.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3517#changelog
http://ghc.haskell.org/trac/ghc/ticket/4019
http://ghc.haskell.org/trac/ghc/ticket/4019#4019: deriving Ord can produce incorrect and inefficient instancesMon, 26 Apr 2010 15:52:54 GMTrl<p>
This bug was spotted by Barak Pearlmutter in <a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2010-April/076762.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-cafe/2010-April/076762.html</a>.
</p>
<pre class="wiki">data T = T Double deriving( Eq, Ord )
*Main> T (0/0) > T (0/0)
True
*Main> (0/0) > (0/0)
False
</pre><p>
This happens because the derived Ord instance only defines compare and relies on default method definitions for everything else. Comparisons involving NaNs always return False, however, compare (arbitrarily) returns GT in this case.
</p>
<p>
Irrespective of this particular wart, this is what GHC ultimately produces for (<=):
</p>
<pre class="wiki">T.$fOrdT_$c<= =
\ (x_ahF :: T.T) (y_ahG :: T.T) ->
case x_ahF of _ { T.T a1_afL ->
case y_ahG of _ { T.T b1_afM ->
case a1_afL of _ { GHC.Types.I# x#_ah1 ->
case b1_afM of _ { GHC.Types.I# y#_ah5 ->
case GHC.Prim.<# x#_ah1 y#_ah5 of _ {
GHC.Bool.False -> GHC.Prim.==# x#_ah1 y#_ah5;
GHC.Bool.True -> GHC.Bool.True
}
}
}
}
}
</pre><p>
Note that the definition uses two comparisons even though (<=) for Double uses just one: (<=##). In general, relying on default method definitions when deriving Ord can be inefficient because the individual comparison operators might very well be faster than compare for the wrapped types.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4019#changelog
http://ghc.haskell.org/trac/ghc/ticket/4139
http://ghc.haskell.org/trac/ghc/ticket/4139#4139: Spurious non-exhaustive pattern match warnings are given using GADTsWed, 16 Jun 2010 16:23:51 GMTblarsen<p>
When using slightly complicated GADTs, GHC gives me erroneous non-exhaustive pattern match warnings. I have attached an example. I have observed this behavior in the four versions of ghc that I tried (6.10.4, and 6.12.{1,2,3}).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4139#changelog
http://ghc.haskell.org/trac/ghc/ticket/6077
http://ghc.haskell.org/trac/ghc/ticket/6077#6077: Respect XDG_CONFIG_HOMEFri, 04 May 2012 22:04:44 GMTSo8res<p>
As of now, ghc creates and uses a "$HOME/.ghc" directory. This is annoying to those who like to keep their $HOME directory clean through use of the XDG_CONFIG_HOME variable. Specifically, it's nice to have all configuration files in "$HOME/.config" instead of polluting "$HOME".
</p>
<p>
It would be great if ghc could create and use its configuration directory in the configuration directory specified by the user.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/6077#changelog
http://ghc.haskell.org/trac/ghc/ticket/7336
http://ghc.haskell.org/trac/ghc/ticket/7336#7336: Defined but not used is not detected for data types with instancesTue, 16 Oct 2012 08:18:07 GMTmaeder<pre class="wiki">module Unused () where
data U = U deriving Show
</pre><p>
does _not_ report
</p>
<pre class="wiki">Unused.hs:3:6: Warning:
Defined but not used: type constructor or class `U'
Unused.hs:3:10: Warning: Defined but not used: data constructor `U'
</pre><p>
This message is only displayed without "deriving".
I know, instances are always exported, but these instances cannot be used.
</p>
<p>
Considering that all types may get Typeable instances, no unused warning would ever be issued for data types.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7336#changelog
http://ghc.haskell.org/trac/ghc/ticket/7860
http://ghc.haskell.org/trac/ghc/ticket/7860#7860: Add more bit fiddling functions to 'integer-gmp'Tue, 23 Apr 2013 22:20:23 GMTlebedev<p>
Current implementation of 'integer-gmp' uses only a subset of "bit fiddling" features, <a class="ext-link" href="http://gmplib.org/manual/Integer-Logic-and-Bit-Fiddling.html"><span class="icon"></span>provided</a> by the GMP library. The ones missing are:
</p>
<pre class="wiki">* mpz_popcount
* mpz_setbit
* mpz_clrbit
</pre><p>
I think it would be nice to add these functions in addition to 'testBitInteger'. Would you accept a patch?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7860#changelog
http://ghc.haskell.org/trac/ghc/ticket/7897
http://ghc.haskell.org/trac/ghc/ticket/7897#7897: MakeTypeRep fingerprints be proper, robust fingerprintsWed, 08 May 2013 14:44:33 GMTsimonpj<p>
A <tt>TypeRep</tt> currently looks like this:
</p>
<pre class="wiki">data TypeRep = TypeRep Fingerprint TyCon [TypeRep]
data TyCon = TyCon {
tyConHash :: Fingerprint,
tyConPackage :: String,
tyConModule :: String,
tyConName :: String }
</pre><p>
If two <tt>TypeRep</tt>s have the same fingerprint they should really describe identical types.
</p>
<p>
But that's not really true today, becuase today the fingerprint for a <tt>TyCon</tt> is obtained by hashing the <em>name</em> of the type constructor (e.g. <tt>base:Data.Maybe.Maybe</tt>), but not its <em>structure</em>. To see how this is non-robust, imagine that
</p>
<pre class="wiki">module M where
data T = MkT S deriving( Typeable )
data S = S1 Int | S2 Bool deriving( Typeable )
</pre><p>
Now I do this:
</p>
<ul><li>Write a program that costructs a value <tt>v::T</tt>, and serialises into a file (a) the <tt>TypeRep</tt> for <tt>v</tt>, and (b) <tt>v</tt> itself.
</li><li>Now I alter the data type declaration for <tt>S</tt>
</li><li>Now I recompile and run the program again, which attempts to read the value back in from the file. It carefully compares <tt>TypeRep</tt>s to be sure that the types are the same... yes, still "M.T".
</li><li>But alas the de-serialisation fails because <tt>S</tt> has been changed.
</li></ul><p>
What we really want is for the fingerprint in a <tt>TypeRep</tt> to really be a hash of the definition of <tt>T</tt> (not just its name), including transitively the fingerprints of all the types mentioned in that definition.
</p>
<p>
In effect, a <tt>TypeRep</tt> is a dynamic type check, and it should jolly well be a robust dynamic type check. This might also matter in a Cloud Haskell application with different components upgraded at different times.
</p>
<p>
As it happens, GHC already computes these fingerprints, to put in interface files. But they aren't used when making the <tt>Typeable</tt> instances for <tt>T</tt>. I think it should be.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7897#changelog
http://ghc.haskell.org/trac/ghc/ticket/7930
http://ghc.haskell.org/trac/ghc/ticket/7930#7930: Nested STM Invariants are lostFri, 24 May 2013 16:26:15 GMTfryguybob<p>
Invariants from a successful nested transaction should be merged with the parent.
</p>
<pre class="wiki">import Control.Concurrent
import Control.Concurrent.STM
main = do
x <- atomically $
do a <- newTVar True
(always (readTVar a) >> retry) `orElse` return ()
return a
atomically (writeTVar x False) -- Should not and does not fail
y <- atomically $
do a <- newTVar True
always (readTVar a) `orElse` return ()
return a
atomically (writeTVar y False) -- Should fail, but does not!
putStrLn "Ahhh!"
z <- atomically $
do a <- newTVar True
always (readTVar a)
return a
atomically (writeTVar z False) -- should and does fail
</pre><p>
I know how to fix this. I'll have a patch with some tests and a fix soon.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7930#changelog
http://ghc.haskell.org/trac/ghc/ticket/7952
http://ghc.haskell.org/trac/ghc/ticket/7952#7952: Can cost-centre annotations be included in -ddump-simpl?Wed, 29 May 2013 21:24:43 GMTnr<p>
I'm trying to diagnose an allocation problem. I'm using both explicit cost-centre annotations and <tt>-fprof -fprof-auto</tt>. I'm running with <tt>+RTS -pa -hc</tt>. To understand what I'm seeing in the profiles, I'm looking at the output from the <tt>ghc-core</tt> tool, which I think include <tt>-ddump-simpl</tt>.
</p>
<p>
If I understand the semantics correctly, allocations are indicated by <tt>let</tt> bindings in the Core. It would be <em>hugely</em> helpful if each of these <tt>let</tt> bindings were annotated with the cost centre to which the allocation is charged. A great aid to debugging!
</p>
<p>
If we can help with this idea, please let me know.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7952#changelog
http://ghc.haskell.org/trac/ghc/ticket/7960
http://ghc.haskell.org/trac/ghc/ticket/7960#7960: Compiling profiling CCS registration .c file takes far too longTue, 04 Jun 2013 11:41:24 GMTduncan<p>
When compiling executables for profiling, ghc generates a .c file something like this:
</p>
<pre class="wiki">#define IN_STG_CODE 0
#include "Rts.h"
#include "Stg.h"
static void prof_init_Main(void) __attribute__((constructor));
static void prof_init_Main(void)
{extern CostCentre Foo_bar_cc[];
REGISTER_CC(Foo_bar_cc);
...
</pre><p>
When there are a large number of CCSs, e.g. 10's of 1,000s (as can easily happen with large projects and using <tt>-fprof-auto</tt>) then of course this .c file and this single C function become very large. The C compiler then takes a very long time to compile it.
</p>
<p>
For example, with a .c file with ~27k lines (so about half that number of CCSs), gcc 4.7.2 with -O1 takes about 20 minutes to compile. With -O0 it takes about 4 seconds. Clearly this version of gcc does not cope very well with this massive function at -O1 level.
</p>
<p>
I suggest that since the initialisation is not performance critical, and it doesn't look like there is a lot to optimise here anyway, that ghc compile this .c file without passing gcc the -O flag.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7960#changelog
http://ghc.haskell.org/trac/ghc/ticket/7961
http://ghc.haskell.org/trac/ghc/ticket/7961#7961: Remove restrictions on promoting GADT'sWed, 05 Jun 2013 02:37:20 GMTdanharaj<p>
(Also allow the promotion of data types whose kind is not (* -> ... -> *))
</p>
<p>
I have been using -XDataKinds lately to explore the sorts of dependently typed programming that are currently possible in GHC. I am particularly interested in DSL's and embedding other languages' type systems into Haskell so that GHC can help verify the correctness of the program fragments I construct for those languages. From my point of view as an end-user, the restrictions on what data get promoted is inconsistent and oftentimes annoying to deal with. There are two related issues on my end:
</p>
<ol><li>The restriction that a data type cannot have a kind mentioning a promoted kind means that the way I stratify my type machinery impacts whether or not GHC will promote everything as I would like.
</li></ol><ol start="2"><li>The inability to use promoted GADT's forces me to encode relationships between my type building blocks in trickier ways, and sometimes I am simply unable to come up with an alternative.
</li></ol><p>
I have found that these issues get in my way as a programmer of modest skill. Oftentimes I will explore a particular design but be forced to abandon it because my "natural" line of reasoning runs into GHC's restrictions. With sufficient cleverness you can do quite a lot of impressive stuff with the current system, but I am often not sufficiently clever nor am I equipped to determine when something is outright <em>impossible</em>.
</p>
<p>
Lifting these restriction, from <em>my</em> point of view, would simplify the machinery a great deal and allow me to do type-level programming that is currently out of my reach. It would make the kind extensions more uniform and more complete to us end-users. <a class="infoneeded ticket" href="http://ghc.haskell.org/trac/ghc/ticket/6024" title="feature request: Allow defining kinds alone, without a datatype (infoneeded)">#6024</a> would complete them in another way.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/7961#changelog
http://ghc.haskell.org/trac/ghc/ticket/8029
http://ghc.haskell.org/trac/ghc/ticket/8029#8029: batch-mode recompilation checking sometimes failsTue, 02 Jul 2013 09:01:10 GMTjwlato<p>
The batch-mode recompilation checker seems to be broken. Suppose you have a source tree with
</p>
<pre class="wiki"> Data/List.hs
Data/Top.hs
</pre><p>
and Data/List.hs defining 'foo' and Data/Top.hs importing Data.List (local file). Compile Data/Top.hs, then rename Data.List so you have
</p>
<pre class="wiki"> Data/List.{hi,o}
Data/OtherList.hs -- exports 'foo'
Data/Top.hs -- imports Data.List and Data.OtherList
Data/Top.{hi.o}
</pre><p>
Attempting to run 'ghc -c Data/Top.hs' will now fail with " Failed to load interface for `Data.OtherList'". This error appears to be specific to built-in modules, if I use a library module (e.g. Data.Vector from the vector package) I instead get an error that multiple definitions of 'foo' are in scope.
</p>
<p>
A test repo is available at <a class="ext-link" href="https://github.com/JohnLato/tripping-octo-avenger"><span class="icon"></span>https://github.com/JohnLato/tripping-octo-avenger</a>
</p>
<p>
Incidentally, everything works if I use 'ghc -c --make'. I think a reasonable fix would be for --make to be on by default for batch-mode compilation as well.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8029#changelog
http://ghc.haskell.org/trac/ghc/ticket/8042
http://ghc.haskell.org/trac/ghc/ticket/8042#8042: `:load *` and `:add *` misbehave in presence of `-fobject-code`Sun, 07 Jul 2013 08:34:21 GMThvr<p>
The documentation states for the <tt>*</tt>-forms of <tt>:add</tt> and <tt>:load</tt> that
</p>
<blockquote class="citation">
<p>
Normally pre-compiled code for a module will be loaded if available, or otherwise the module will be compiled to byte-code. Using the <tt>*</tt> prefix forces a module to be loaded as byte-code.
</p>
</blockquote>
<p>
However, this seems to be ignored when <tt>-fobject-code</tt> has been enabled. In that case, the compiled code is <em>always</em> used, regardless of whether the <tt>*</tt>-form is used.
</p>
<p>
Having <tt>-fobject-code</tt> enabled is very useful for large projects as it cuts down loading times, whereas being able to use the <tt>*</tt>-forms on individual modules from the target set allows for being inside the module context, which is very useful for integration with Emacs (and IDEs), or for being able to set breakpoints.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8042#changelog
http://ghc.haskell.org/trac/ghc/ticket/8043
http://ghc.haskell.org/trac/ghc/ticket/8043#8043: Feature Request : Qualified module exportsMon, 08 Jul 2013 03:52:35 GMTerikd<p>
I quite like the practice of using <tt>-XNoImplicitPrelude</tt> and then defining my own (often per-project) Prelude doing things like:
</p>
<pre class="wiki">module MyProject.Prelude
( module P
)
import Data.Text as P (Text)
import Prelude as P hiding (head, init, tail, last)
</pre><p>
As an extension to the above idea, I would like to add qualified module exports defined so that I can do this:
</p>
<pre class="wiki">module MyProject.Prelude
( module P
, qualified module T
)
import Data.Text as P (Text)
import Prelude as P hiding (head, init, tail, last)
import qualified Data.Text as T
</pre><p>
so that any file which imports <tt>MyProject.Prelude</tt> will then have all the identifiers that they would normally get if they did:
</p>
<pre class="wiki">import qualified Data.Text as T
</pre><p>
Is this something that would have to go through the Haskell Next procedure? If so, how does one get that kicked off?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8043#changelog
http://ghc.haskell.org/trac/ghc/ticket/8045
http://ghc.haskell.org/trac/ghc/ticket/8045#8045: Move I/O manager benchmarks into the GHC treeMon, 08 Jul 2013 09:50:39 GMTtibbe<p>
When we developed the scalable I/O manager (i.e. the first version that used epoll) we wrote a bunch of benchmarks that were never moved to the GHC tree or integrated into the make system:
</p>
<blockquote>
<p>
<a class="ext-link" href="https://github.com/tibbe/event/tree/master/benchmarks"><span class="icon"></span>https://github.com/tibbe/event/tree/master/benchmarks</a>
</p>
</blockquote>
<p>
It would be nice to move this into the GHC tree to catch future regressions and use them when trying to make improvements.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8045#changelog
http://ghc.haskell.org/trac/ghc/ticket/8046
http://ghc.haskell.org/trac/ghc/ticket/8046#8046: Make the timer management scale better across multicoreMon, 08 Jul 2013 09:53:23 GMTtibbe<p>
Commit <a class="changeset" href="http://ghc.haskell.org/trac/ghc/changeset/2d5eccdf1cfb389074cc2e5b52ae40b535c3b235/ghc" title="IO manager: Edit the timeout queue directly, rather than using an edit ...">2d5eccdf1cfb389074cc2e5b52ae40b535c3b235</a>
</p>
<pre class="wiki">Author: Ian Lynagh <ian@well-typed.com>
Date: Sat Jun 8 20:19:59 2013 +0100
IO manager: Edit the timeout queue directly, rather than using an edit list
Fixes #7653.
</pre><p>
undid an optimization to the management of timeouts (to fix a bug, which is good). We should check how much this hurt performance, but it might be better to rewrite the timeout management altogether. The current scheme scales poorly to several cores. We should probably have one priority queue per core and use an efficient mutable data structure.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8046#changelog
http://ghc.haskell.org/trac/ghc/ticket/8050
http://ghc.haskell.org/trac/ghc/ticket/8050#8050: add a required wrapper around plugin installersWed, 10 Jul 2013 17:41:08 GMTnfrisby<p>
While trying to expand <a href="http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/compiler-plugins.html#writing-compiler-plugins">the CoreMonad.reinitializeGlobals mechanism</a>, I proposed an alternative that SPJ noted could be more generally useful.
</p>
<p>
The nub of the idea is to require plugins to apply a distinguished function to their installation function. Instead of defining the plugin as
</p>
<pre class="wiki">module APlugin (plugin) where
import GhcPlugins
plugin :: Plugin
plugin = defaultPlugin {installCoreToDos = install}
install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]
install = …
</pre><p>
plugins would be defined as
</p>
<pre class="wiki">module APlugin (plugin) where
import GhcPlugins
plugin :: Plugin
plugin = defaultPlugin {installCoreToDos = mkPluginInstaller install}
install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo]
install = install = …
</pre><p>
The new function <tt>mkPluginInstaller</tt> provides a hook for GHC developers to process the plugin, hidden from the plugin author. For example, it could encapsulate the current <tt>reinitializeGlobals</tt> mechanism.
</p>
<p>
I'm not sure if using an abstract type to enforce that this function is called is necessary, but it's an option.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8050#changelog
http://ghc.haskell.org/trac/ghc/ticket/8057
http://ghc.haskell.org/trac/ghc/ticket/8057#8057: Warn when supplying version number to package-qualified importSun, 14 Jul 2013 07:55:08 GMTLemming<pre class="wiki">$ ghci -XPackageImports
GHCi, version 7.8.3: ...
Prelude> import "transformers-0.3.0.0" Control.Monad.Trans.List
<no location info>:
Could not find module ‘Control.Monad.Trans.List’
It is not a module in the current program, or in any known package.
Prelude> import "transformers" Control.Monad.Trans.List
Prelude Control.Monad.Trans.List>
</pre><p>
The import with explicit package name works, if I omit the package version. I think GHC should at least warn that providing a version does not work.
</p>
<p>
See also <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/2362" title="feature request: allow full import syntax in GHCi (closed: fixed)">#2362</a>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8057#changelog
http://ghc.haskell.org/trac/ghc/ticket/8060
http://ghc.haskell.org/trac/ghc/ticket/8060#8060: Undefined symbols when using Template Haskell linked from another object with unexposed modulesMon, 15 Jul 2013 17:17:54 GMTtvynr<p>
I have constructed two Cabal projects named "first" and "second". The "first" project defines three files: Logging.hs (which provides some basic logging functionality) and FirstExample.hs and FirstDependent.hs (the latter of which imports the former). In the cabal file, only Logging and FirstDependent are exposed modules. FirstDependent uses a Template Haskell function "loggingFunctions" which defines logging functions for that module. Using cabal or cabal-dev to build this package works quite nicely.
</p>
<p>
The second project depends on the first project and contains a single file, Second.hs. This file imports Logging but neither of the other two files. It also uses the loggingFunctions routine to generate local logging functions. The presence of the "$(loggingFunctions)" splice in Second.hs makes the problem visible, but the real problem is in the first project. Upon compilation of the "second" project with cabal or cabal-dev, the following error is generated:
</p>
<pre class="wiki">cabal-dev -s ../cabal-dev-sandbox --with-cabal-install=cabal configure
Resolving dependencies...
Configuring second-0.1...
cabal-dev -s ../cabal-dev-sandbox --with-cabal-install=cabal build
Building second-0.1...
Preprocessing library second-0.1...
[1 of 1] Compiling Second ( lib-src/Second.hs, dist/build/Second.o )
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 containers-0.5.0.0 ... linking ... done.
Loading package filepath-1.3.0.1 ... linking ... done.
Loading package old-locale-1.0.0.5 ... linking ... done.
Loading package time-1.4.0.1 ... linking ... done.
Loading package bytestring-0.10.0.2 ... linking ... done.
Loading package unix-2.6.0.1 ... linking ... done.
Loading package directory-1.2.0.1 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package text-0.11.3.1 ... linking ... done.
Loading package parsec-3.1.3 ... linking ... done.
Loading package network-2.4.1.2 ... linking ... done.
Loading package process-1.1.0.2 ... linking ... done.
Loading package hslogger-1.2.1 ... linking ... done.
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package first-0.2 ... linking ... ghc: /home/some-directories/example/first/../cabal-dev-sandbox//lib/first-0.2/ghc-7.6.1.20121207/HSfirst-0.2.o: unknown symbol `firstzm0zi2_FirstExample_zdfShowErrorSpec3_closure'
ghc: unable to load package `first-0.2'
make[1]: *** [build] Error 1
</pre><p>
Upon further investigation, it would seem that the .o file constructed to represent the "first" project has not been completely constructed:
</p>
<pre class="wiki">$ objdump -t cabal-dev-sandbox/lib/first-0.2/ghc-7.6.1.20121207/HSfirst-0.2.o | grep '\*UND\*' | grep first
00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczg_info
00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfShowErrorSpec3_closure
00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczl_info
00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfEqErrorSpeczuzdczeze_info
00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczlze_info
00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdccompare_info
00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczgze_info
</pre><p>
(While the above dump is for ghc 7.6.1, this has also been tested on ghc 7.6.3 as well as on both i386- and amd64-based OS installs.)
</p>
<p>
If the "$(loggingFunctions)" splice is removed from Second.hs, then the project builds (presumably because the logic used by non-Template Haskell projects for linking differs from that of Template Haskell projects).
</p>
<p>
Fortunately, it seems that exposing every module of the "first" project resolves this issue. But please note that the FirstExample.hs and FirstDependent.hs files are completely unrelated to the Second.hs file; the latter does not depend on the former in any way. It seems strange that I can't use Template Haskell across projects without exposing all of my project modules.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8060#changelog
http://ghc.haskell.org/trac/ghc/ticket/8061
http://ghc.haskell.org/trac/ghc/ticket/8061#8061: Support for Complex Double in Foreign Function InterfaceMon, 15 Jul 2013 21:27:14 GMTdsamperi<p>
Currently the FFI only permits BASIC return types like Double, Int, Bool, etc., but NOT
Complex Double (only slightly non-basic!). This makes it impossible to import a Fortran
function (not subroutine) that returns a complex value. Adding support for Complex Double
would make it easier to interface to external libs like BLAS and LAPACK; without this
support wrapper C libs must be used, and these are not standardized (the Haskell package
hs-linear-algebra currently has some problems related to this).
</p>
<p>
Thus adding Foreign support for Complex Double (not just through Ptr) would open up
access to a large collection of external Fortran libs for the Haskell community. Currently
I get the message "Unacceptable return type in FFI" when I try to return
IO (ComplexType).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8061#changelog
http://ghc.haskell.org/trac/ghc/ticket/8064
http://ghc.haskell.org/trac/ghc/ticket/8064#8064: Warning out when "undefined" value has been used.Tue, 16 Jul 2013 03:32:19 GMTfreizl<p>
Programmer may like to use "undefined" to define a function or value, which usually means "later implementation".
</p>
<p>
However, people might forget to implement it thus cause run time error.
Wish GHC will show some warning/errors at compilation.
</p>
<p>
This idea comes from this article (<a class="ext-link" href="http://www.devalot.com/articles/2013/07/why-haskell.html"><span class="icon"></span>http://www.devalot.com/articles/2013/07/why-haskell.html</a>)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8064#changelog
http://ghc.haskell.org/trac/ghc/ticket/8078
http://ghc.haskell.org/trac/ghc/ticket/8078#8078: Core lint failure for profiled codeSat, 20 Jul 2013 22:19:42 GMTezyang<p>
Probably related to the cardinality changes. Here is the dump:
</p>
<pre class="wiki">=====> T4492(profasm) 3361 of 3686 [2, 51, 0]
cd ./indexed-types/should_compile && '/srv/code/ghc-build-sandbox/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T4492.hs -O -prof -static -auto-all >T4492.comp.stderr 2>&1
Compile failed (status 256) errors were:
*** Core Lint errors : in result of CorePrep ***
{-# LINE 12 "T4492.hs #-}: Warning:
[RHS of T4492.$fCMaybe_$cgo :: forall a_aex.
T4492.C a_aex =>
forall b_ae0.
(forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_ae0 -> a1_ae1)
-> Data.Maybe.Maybe a_aex
-> T4492.F (Data.Maybe.Maybe a_aex) b_ae0]
Demand type has 4 arguments, rhs has 3 arguments, T4492.$fCMaybe_$cgo
Binder's strictness signature: DmdType <C(C(S)),1*C1(C1(U))><L,U><L,U><L,U>
*** Offending Program ***
T4492.go [InlPrag=INLINE]
:: forall a_adZ.
T4492.C a_adZ =>
forall b_ae0.
(forall a_ae1. Data.Maybe.Maybe a_ae1 -> b_ae0 -> a_ae1)
-> a_adZ -> T4492.F a_adZ b_ae0
[GblId[ClassOp],
Arity=1,
Caf=NoCafRefs,
Str=DmdType <S,U>,
Unf=OtherCon []]
T4492.go =
\ (@ a_adZ) (tpl_sgH [Occ=Once] :: T4492.C a_adZ) ->
tpl_sgH
`cast` (T4492.NTCo:C[0] <a_adZ>
:: T4492.C a_adZ
~#
(forall b_ae0.
(forall a_ae1. Data.Maybe.Maybe a_ae1 -> b_ae0 -> a_ae1)
-> a_adZ -> T4492.F a_adZ b_ae0))
T4492.$fCMaybe1
:: forall a_aex.
T4492.C a_aex =>
forall b_afH.
(forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_afH -> a1_ae1)
-> Data.Maybe.Maybe a_aex -> b_afH -> T4492.F a_aex b_afH
[GblId,
Arity=4,
Caf=NoCafRefs,
Str=DmdType <C(C(S)),1*C1(C1(U))><L,U><L,U><L,U>,
Unf=OtherCon []]
T4492.$fCMaybe1 =
\ (@ a_aex)
($dC_sgI [Occ=OnceL] :: T4492.C a_aex)
(@ b_afH)
(f_sgJ
:: forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_afH -> a1_ae1)
(a1_sgK [Occ=OnceL] :: Data.Maybe.Maybe a_aex)
(b1_sgL [Occ=OnceL] :: b_afH) ->
scctick<go>
let {
sat_sgM [Occ=Once] :: a_aex
[LclId, Str=DmdType]
sat_sgM = f_sgJ @ a_aex a1_sgK b1_sgL } in
($dC_sgI
`cast` (T4492.NTCo:C[0] <a_aex>
:: T4492.C a_aex
~#
(forall b_ae0.
(forall a_ae1. Data.Maybe.Maybe a_ae1 -> b_ae0 -> a_ae1)
-> a_aex -> T4492.F a_aex b_ae0)))
@ b_afH f_sgJ sat_sgM
T4492.$fCMaybe_$cgo
:: forall a_aex.
T4492.C a_aex =>
forall b_ae0.
(forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_ae0 -> a1_ae1)
-> Data.Maybe.Maybe a_aex -> T4492.F (Data.Maybe.Maybe a_aex) b_ae0
[GblId,
Arity=3,
Caf=NoCafRefs,
Str=DmdType <C(C(S)),1*C1(C1(U))><L,U><L,U><L,U>,
Unf=OtherCon []]
T4492.$fCMaybe_$cgo =
(\ (@ a_aex)
(eta_B3 [Occ=Once] :: T4492.C a_aex)
(@ b_afH)
(eta_B2 [Occ=Once]
:: forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_afH -> a1_ae1)
(eta_B1 [Occ=Once] :: Data.Maybe.Maybe a_aex) ->
T4492.$fCMaybe1 @ a_aex eta_B3 @ b_afH eta_B2 eta_B1)
`cast` (forall a_aex.
<T4492.C a_aex>
-> forall b_afH.
<forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_afH -> a1_ae1>
-> <Data.Maybe.Maybe a_aex>
-> Sym (T4492.TFCo:R:FMaybeb[0] <a_aex> <b_afH>)
:: (forall a_aex.
T4492.C a_aex =>
forall b_afH.
(forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_afH -> a1_ae1)
-> Data.Maybe.Maybe a_aex -> b_afH -> T4492.F a_aex b_afH)
~#
(forall a_aex.
T4492.C a_aex =>
forall b_afH.
(forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_afH -> a1_ae1)
-> Data.Maybe.Maybe a_aex
-> T4492.F (Data.Maybe.Maybe a_aex) b_afH))
T4492.$fCMaybe [InlPrag=INLINE (sat-args=0)]
:: forall a_aex. T4492.C a_aex => T4492.C (Data.Maybe.Maybe a_aex)
[GblId[DFunId(nt)],
Arity=3,
Caf=NoCafRefs,
Str=DmdType <C(C(S)),1*C1(C1(U))><L,U><L,U><L,U>,
Unf=OtherCon []]
T4492.$fCMaybe =
(\ (@ a_aex)
(eta_B3 [Occ=Once] :: T4492.C a_aex)
(@ b_afH)
(eta_B2 [Occ=Once]
:: forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_afH -> a1_ae1)
(eta_B1 [Occ=Once] :: Data.Maybe.Maybe a_aex) ->
T4492.$fCMaybe1 @ a_aex eta_B3 @ b_afH eta_B2 eta_B1)
`cast` (forall a_aex.
<T4492.C a_aex>
-> (forall b_afH.
<forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_afH -> a1_ae1>
-> <Data.Maybe.Maybe a_aex>
-> Sym (T4492.TFCo:R:FMaybeb[0] <a_aex> <b_afH>))
; Sym (T4492.NTCo:C[0] <Data.Maybe.Maybe a_aex>)
:: (forall a_aex.
T4492.C a_aex =>
forall b_afH.
(forall a1_ae1. Data.Maybe.Maybe a1_ae1 -> b_afH -> a1_ae1)
-> Data.Maybe.Maybe a_aex -> b_afH -> T4492.F a_aex b_afH)
~#
(forall a_aex. T4492.C a_aex => T4492.C (Data.Maybe.Maybe a_aex)))
*** End of Offense ***
<no location info>:
Compilation had errors
*** unexpected failure for T4492(profasm)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8078#changelog
http://ghc.haskell.org/trac/ghc/ticket/8079
http://ghc.haskell.org/trac/ghc/ticket/8079#8079: Redo T7919 and TH_spliceE5_prof with a cabal fileSat, 20 Jul 2013 22:47:20 GMTezyang<p>
Right now T7919 fails because the new dynamic-by-default GHC means that Template Haskell must be built with dynamic; of course, GHC isn't clever enough to figure this out. If we Cabalize the test, the example should start building again (and if they don't, well, that's a bug!)
</p>
<p>
TH_spliceE5_prof can also use this treatment.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8079#changelog
http://ghc.haskell.org/trac/ghc/ticket/8086
http://ghc.haskell.org/trac/ghc/ticket/8086#8086: Minimal install for GHCTue, 23 Jul 2013 12:42:21 GMTgidyn<p>
Installing GHC on a shared server requires a minimal footprint, without GHCi, profiling, debugging, documentation, or anything else not needed for regular building and installing. And anything stripable should be striped, if it isn't already.
</p>
<p>
It would be great if the configuration script would support a --minimal option.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8086#changelog
http://ghc.haskell.org/trac/ghc/ticket/8096
http://ghc.haskell.org/trac/ghc/ticket/8096#8096: Add fudge-factor for performance tests run on non-validate buildsSat, 27 Jul 2013 05:47:44 GMTezyang<p>
Since I'm not going to get around to this immediately, Trac'ifying for posterity:
</p>
<p>
These tests have been doing better than expected in the nightlies
for some while.
</p>
<pre class="wiki"> Unexpected failures:
perf/compiler T3064 [stat too good] (normal)
perf/compiler T3294 [stat too good] (normal)
perf/compiler T5642 [stat too good] (normal)
perf/haddock haddock.Cabal [stat too good] (normal)
perf/haddock haddock.base [stat too good] (normal)
</pre><p>
Unfortunately, fixing them is not a simple matter of shifting
the ranges up, since the tests only exceed expectations on
a /perf/ build, so on a normal build such as 'quick', these
tests all pass normally.
</p>
<p>
I could bump up the upper bounds so that the builder stops bleating
about them; perhaps we could do something more complicated where the
expected performance depends on what level of optimization GHC was built
with (but I don't know how to implement this.)
</p>
<hr />
<p>
The problem with just widening the bounds to cover 2 different types of
build is that it increases the chance that performance changes won't
actually be noticed by thge person responsible.
</p>
<p>
Having different bounds for different build configurations is a pain,
because (a) the testsuite has to work out which set of bounds to use,
and (b) you now have even more wobbly values to keep up-to-date.
</p>
<p>
I think perhaps the best thing would be to add some sort of (per-test?)
fudge factor for non-validate builds. That way validate will still find
performance regressions, like it does today, but other builds are less
likely to give false positives. (Igloo)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8096#changelog
http://ghc.haskell.org/trac/ghc/ticket/8099
http://ghc.haskell.org/trac/ghc/ticket/8099#8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inliningSat, 27 Jul 2013 21:25:21 GMTjberryman<p>
I just remembered an old idea I put to the GHC user's list <a class="ext-link" href="http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg22119.html"><span class="icon"></span>here</a>, and thought I should present it here.
</p>
<p>
As I understand it GHC inlines inlines only after a function is fully applied with respect to the syntactic left-hand side, so in order to control inlining and sharing, we sometimes see strange things like:
</p>
<pre class="wiki">{-# INLINE foo #-}
foo :: a -> b -> c
foo a = \b -> ...
</pre><p>
It would be nice to be able to define the function syntactically in the way that's the most clear (e.g. in pointfree style, etc.) and specify at what point to inline something like this:
</p>
<pre class="wiki">foo :: a -> {-# INLINE #-} b -> c
foo a b = ...
-- or:
foo = ...
</pre><p>
...which tells the compiler to inline after applying the arguments to the left of the pragma, and GHC would do whatever trivial (I assume?) eta-conversion was required.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8099#changelog
http://ghc.haskell.org/trac/ghc/ticket/8109
http://ghc.haskell.org/trac/ghc/ticket/8109#8109: Type family patterns should support as-patterns.Thu, 01 Aug 2013 23:03:31 GMTcarlhowells<p>
I recently wrote code similar to the following:
</p>
<pre class="wiki">{-# LANGUAGE DataKinds, ScopedTypeVariables, TypeOperators, TypeFamilies #-}
{-# LANGUAGE PolyKinds, FlexibleInstances, FlexibleContexts #-}
import GHC.TypeLits
data P n = P
fromNat :: forall (p :: Nat -> *) (n :: Nat). SingI n => p n -> Integer
fromNat _ = fromSing (sing :: Sing n)
class C (a :: [Nat]) where
type T a :: *
val :: p a -> T a
instance SingI n => C '[n] where
type T '[n] = Integer
val _ = fromNat (P :: P n)
instance (SingI n, C (n2 ': ns)) => C (n ': n2 ': ns) where
type T (n ': n2 ': ns) = (Integer, T (n2 ': ns))
val _ = (fromNat (P :: P n), val (P :: P (n2 ': ns)))
</pre><p>
There were semantic constraints in my case that made an empty list nonsensical, so it wasn't an appropriate base case. But the resulting effort in ensuring type family patterns didn't overlap got unwieldy. I would have much preferred to write that second instance more like this:
</p>
<pre class="wiki">instance (SingI n, C ns) => C (n ': ns@(_ ': _)) where
type T (n ': ns) = (Integer, T ns)
val _ = (fromNat (P :: P n), val (P :: P ns))
</pre><p>
The reasoning here is identical to as-patterns in value-level pattern matching. If you only want to match an expression when it has a particular sub-structure, it's way more convenient to do it with an as-pattern.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8109#changelog
http://ghc.haskell.org/trac/ghc/ticket/8114
http://ghc.haskell.org/trac/ghc/ticket/8114#8114: STG lint panicSun, 04 Aug 2013 17:38:07 GMTPtharien's Flame<p>
While attempting to build <tt>thyme</tt> from Hackage with core, stg, and cmm linting and -O2 enabled, GHC crashed with an internal panic. See attached terminal log.
</p>
<pre class="wiki">rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.6.3
rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ cabal --version
cabal-install version 1.16.0.2
using version 1.16.0 of the Cabal library
rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ which ghc
/usr/local/bin/ghc
rrdhcp-10-32-234-247:thyme-0.2.4.1 Alexander$ which cabal
/Users/Alexander/Library/Haskell/bin/cabal
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8114#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/8147
http://ghc.haskell.org/trac/ghc/ticket/8147#8147: Exponential behavior in instance resolution on fixpoint-of-sumWed, 21 Aug 2013 01:47:57 GMTjkoppel<p>
Doing instance resolution on a fixpoint-of-sum type takes a very long time. This is possibly the same issue as issue <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/5642" title="bug: Deriving Generic of a big type takes a long time and lots of space (new)">#5642</a>.
</p>
<p>
These are the numbers I see for various n:
</p>
<pre class="wiki">10 : 0.329s
20 : 0.479s
40 : 0.935s
80 : 2.821s
160 : 11.694s
320 : 1m30.39s
640: Ran for over 1 hour without terminating
</pre><p>
This uses a couple of attached support files. Apologies for not being able to reduce further.
</p>
<pre class="wiki">-- Test.hs
{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, UndecidableInstances, OverlappingInstances, TypeOperators, DeriveFunctor, TemplateHaskell #-}
module Test where
import Control.Monad
import Lib
import TH
{-
With n=3, produces
data X1 e = X1 e deriving (Functor)
data X2 e = X2 e deriving (Functor)
data X3 e = X3 e deriving (Functor)
type X = X1 :+: X2 :+: X3
-}
$(let n = 320 in
liftM concat $ sequence [liftM concat $ mapM mkDec $ map (('X':).show) [1..n]
, makeSumType "X" (map (('X':).show) [1..n])])
data Y0 e = Y0 e deriving ( Functor )
type X' = Y0 :+: X
class Lift f g where
lift' :: f (Fix g) -> Fix g
instance (Lift f g, Lift f' g) => Lift (f :+: f') g where
lift' x = case x of
L e -> lift' e
R e -> lift' e
instance (Functor f, f :<: g) => Lift f g where
lift' = In . inj
cata :: (Functor f) => (f a -> a) -> Fix f -> a
cata f = f . fmap (cata f) . out
lift :: Fix X -> Fix X'
lift = cata lift'
</pre><p>
Virtually all the time is spent in compiling lift. For example, with n=640, commenting out lift makes it compile in around 2 seconds.
</p>
<p>
Interestingly, when I add the following code, compilation times only increase by 10-20%. In the original code where I encountered this issue, doing so doubles compilation time.
</p>
<pre class="wiki">
instance Lift Y0 X where
lift' = undefined
lower :: Fix X' -> Fix X
lower = cata lift'
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8147#changelog
http://ghc.haskell.org/trac/ghc/ticket/8150
http://ghc.haskell.org/trac/ghc/ticket/8150#8150: Foreign export requires redundant type signatureWed, 21 Aug 2013 17:50:25 GMTevincarofautumn<p>
With a source file such as:
</p>
<pre class="wiki">module FFITest where
foreign export ccall "function"
function :: IO ()
function :: IO ()
function = putStrLn "Hello, world!"
</pre><p>
The second <tt>function :: IO ()</tt> signature is required to satisfy <tt>-fwarn-missing-signatures</tt>, even though a signature is already present in the <tt>foreign export</tt> declaration, and the types are required to be the same.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8150#changelog
http://ghc.haskell.org/trac/ghc/ticket/8159
http://ghc.haskell.org/trac/ghc/ticket/8159#8159: Uses of Binary decode should have a proper error messageFri, 23 Aug 2013 06:47:41 GMTnh2<p>
In <a class="infoneeded ticket" href="http://ghc.haskell.org/trac/ghc/ticket/8144" title="bug: Interface hashes include time stamp of dependent files (UsageFile mtime) (infoneeded)">#8144</a> I changed the interface file format.
</p>
<p>
That can happen without you noticing because it just uses the Binary instance.
</p>
<p>
To deserialize it, we also use Binary. When that fails, the error message is
</p>
<pre class="wiki">Binary.get(Usage): 50
</pre><p>
The error message should at least also mention:
</p>
<pre class="wiki">Reading the interface file failed
</pre><p>
This is not a specific problem with interface files (it is actually a minor problem there since ghc will refrain from reading .hi files created by an older version), but it is in development, and independent from that, all uses of Binary decode should be guarded as it is a very partial function.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8159#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/8165
http://ghc.haskell.org/trac/ghc/ticket/8165#8165: Use GeneralizedNewtypeDeriving to automatically create associated type familiesFri, 23 Aug 2013 20:56:05 GMTMikeIzbicki<p>
Here's a simple example:
</p>
<pre class="wiki">class C a where
type T a
instance C Int where
type T Int = Bool
newtype NT = NT Int
deriving C
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8165#changelog
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/8171
http://ghc.haskell.org/trac/ghc/ticket/8171#8171: Extending ExtendedDefaultRulesSat, 24 Aug 2013 20:33:52 GMTekmett<p>
The current <tt>ExtendedDefaultRules</tt> (see <a href="http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluation.html#extended-default-rules">manual page</a>) is set up in a way that largely prevents it from being used for scenarios beyond what they get used for in GHCi today.
</p>
<p>
It would be great if there was an extra class that could be included in the list of acceptable classes for Rule 3.
</p>
<pre class="wiki">class Defaulting a
</pre><p>
The proposed change would be that Rule 3 under EDR can be be relaxed to: At least one of the classes Ci is numeric, or is <tt>Show</tt>, <tt>Eq</tt>, <tt>Ord</tt> or <tt>Defaulting</tt>.
</p>
<p>
I went with <tt>Defaulting</tt> rather than <tt>Default</tt>, because <tt>Default</tt> is a common class in use across the ecosystem from the <tt>data-default</tt> package, and I wanted to avoid gratuitous fallout.
</p>
<p>
This would permit projects like Shae Erisson's <tt>ghclive</tt> from last year that need to use defaulting to not have to shoe-horn unnecessary <tt>Show</tt> constraints onto functions.
</p>
<p>
Even better would be for that class to be polykinded!
</p>
<p>
That opens up possibilities for expert users to get defaulting to fire on arguments of other kinds, which is impossible under the current EDR.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8171#changelog
http://ghc.haskell.org/trac/ghc/ticket/8173
http://ghc.haskell.org/trac/ghc/ticket/8173#8173: GHC uses nubMon, 26 Aug 2013 12:12:55 GMTnh2<p>
nub is O(n²).
</p>
<p>
I bet all usages have Ord instances.
</p>
<p>
<a class="ext-link" href="https://github.com/nh2/haskell-ordnub"><span class="icon"></span>https://github.com/nh2/haskell-ordnub</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8173#changelog
http://ghc.haskell.org/trac/ghc/ticket/8178
http://ghc.haskell.org/trac/ghc/ticket/8178#8178: Need TypeRep for Symbol and numeric type literals; and Typeable instancesTue, 27 Aug 2013 11:45:28 GMTsimonpj<p>
Nicolas Trangez points out that we don't have a <tt>TypeRep</tt> for types involving literal strings or numerics. E.g. what is <tt>(typeRep (undefined :: Proxy "foo"))</tt>?
</p>
<p>
Here is Nicolas's example:
</p>
<pre class="wiki">{-# LANGUAGE DataKinds,
KindSignatures,
DeriveFunctor,
DeriveDataTypeable #-}
module Main where
import Data.Typeable
import GHC.TypeLits
data NoSymbol n a b = NoSymbol a b
deriving (Typeable)
data WithSymbol (n :: Symbol) a b = WithSymbol a b
deriving (Typeable)
data Sym
deriving (Typeable)
main :: IO ()
main = do
print $ typeOf (undefined :: NoSymbol Sym Int Int)
let d = undefined :: WithSymbol "sym" Int Int
{-
print $ typeOf d
No instance for (Typeable Symbol "sym")
arising from a use of ‛typeOf’
-}
return ()
</pre><p>
Just as types contain literal strings and natural numbers, so too must <tt>TypeRep</tt>, in some way. Once we have a suitable <tt>TypeRep</tt> we can make built-in instance for <tt>Typeable</tt> that return the appropriate representation.
</p>
<p>
At the moment we have (in <tt>Data.Typeable.Internals</tt>):
</p>
<pre class="wiki">data TypeRep = TypeRep {-# UNPACK #-} !Fingerprint TyCon [TypeRep]
data TyCon = TyCon {
tyConHash :: {-# UNPACK #-} !Fingerprint,
tyConPackage :: String,
tyConModule :: String,
tyConName :: String
}
</pre><p>
with instances for Eq and Ord. Perhaps we need
</p>
<pre class="wiki">data TypeRep
= TcApp {-# UNPACK #-} !Fingerprint TyCon [TypeRep]
| TcSym String
| TcNat Integer
</pre><p>
or something like that? I'm not certain. I think Iavor is going to think about it.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8178#changelog
http://ghc.haskell.org/trac/ghc/ticket/8206
http://ghc.haskell.org/trac/ghc/ticket/8206#8206: Add support for Portable Native ClientSat, 31 Aug 2013 11:25:02 GMTguest<h2 id="Motivation">Motivation</h2>
<p>
<a class="ext-link" href="http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable-native-client"><span class="icon"></span>Portable Native Client</a> (PNaCl) is a feature in Google Chrome which (roughly) allows it to use LLVM bitcode like browsers use javascript today. The bitcode is downloaded, validated, compiled, and (safely) executed, with access to an API for manipulating the DOM of the page which loaded it. The dream: Haskell executed in the browser at near-native speed. Unfortunately, while GHC has an LLVM backend, the bitcode it generates doesn't satisfy the PNaCl validator.
</p>
<h2 id="PortableNativeClient">Portable Native Client</h2>
<p>
The user visits a page with an <embed> tag pointing to a "pexe" - a PNaCl bitcode file. The bitcode is downloaded and streamed first into a code validator, and then into a compiler. The resulting machine code is then executed as a memory-protected process. The <a class="ext-link" href="https://developers.google.com/native-client/pepperc/"><span class="icon"></span>Pepper API</a>, a library Google provides, provides access to the browser for things like connecting to websockets, playing audio, and communicating with javascript running on the page.
</p>
<p>
PNaCl is present in Chrome 29 (go to chrome://flags to enable it), and will be enabled for arbitrary sources (the "open web") in Chrome 30. Mozilla have announced that they don't intend to support Native Client.
</p>
<h2 id="TheEasily-Fixed">The Easily-Fixed</h2>
<p>
The pexe bitcode format is a frozen subset of LLVM bitcode. The PNaCl toolchain provides <tt>pnacl-finalize</tt>, which translates LLVM bitcode into pexe bitcode.
</p>
<p>
PNaCl <a class="ext-link" href="http://www.chromium.org/nativeclient/pnacl/bitcode-abi##callingconventions"><span class="icon"></span>only allows</a> the standard "ccc" calling convention, whereas GHC likes to use its own "cc 10" calling convention. You can make GHC use ccc by using an unregisterised build, for a slow-down factor of about 2.
</p>
<p>
It seems likely that code-next-to-tables will upset the validator. If so, this can be turned off for a small performance hit.
</p>
<h2 id="TheNot-So-Easily-Fixed">The Not-So-Easily-Fixed</h2>
<p>
The validator requires that requests for IO are sent to Pepper. PNaCl also requires that you use newlib instead of glibc. Spawning new processes is forbidden (although creating pthreads is fine). It also seems likely that the validator with take umbrage at calls to <tt>mmap</tt>, which the GHC runtime uses to request memory allocation.
</p>
<p>
It seems, therefore, that significant chunks of the RTS will have to be ported.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8206#changelog
http://ghc.haskell.org/trac/ghc/ticket/8207
http://ghc.haskell.org/trac/ghc/ticket/8207#8207: Pretty Printer for textual version of Language (name) in DynFlagsSun, 01 Sep 2013 03:02:13 GMTFuuzetsu<p>
I feel that the GHC API could benefit from a Show instance for Language in DynFlags.hs.
</p>
<p>
Currently, if we want to display the language being used we have to do something like
</p>
<pre class="wiki"> foo inf = case hmi_language inf of
Nothing -> Nothing
Just Haskell98 -> Just "Haskell98"
Just Haskell2010 -> Just "Haskell2010"
</pre><p>
This is pretty much just the Show instance (over Maybe) and Haskell can derive it for us automatically: we just need to change <tt>deriving Enum</tt> to <tt>deriving (Enum, Show)</tt>. The above solution is not the most robust ever as if this data type is ever changed, this starts to form an incomplete pattern. If we have a catch all <tt>_</tt>, GHC complains about overlapping patterns. Easily solved with <tt>show <$> hmi_language inf</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8207#changelog
http://ghc.haskell.org/trac/ghc/ticket/8211
http://ghc.haskell.org/trac/ghc/ticket/8211#8211: ghc -c recompiles TH every time while --make doesn'tMon, 02 Sep 2013 01:32:14 GMTnh2<p>
<a class="ext-link" href="https://github.com/nh2/ghc-bug-recompiles-th-on-c"><span class="icon"></span>https://github.com/nh2/ghc-bug-recompiles-th-on-c</a>
</p>
<pre class="wiki">ghc -c Test.hs # compiles
ghc -c Test.hs # compiles (and loads TH) again
</pre><p>
I would expect ghc to print
</p>
<pre class="wiki">compilation IS NOT requried
</pre><p>
since ghc --make does not recompile either, and the created .hi and .o files are identical.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8211#changelog
http://ghc.haskell.org/trac/ghc/ticket/8220
http://ghc.haskell.org/trac/ghc/ticket/8220#8220: Macros / functions for source locationTue, 03 Sep 2013 18:18:42 GMTwojteknar<p>
In GNAT (Ada compiler) there is a special package with functions (evaluated at compile time) that return source location and enclosing entity name. This is very useful for logging and debugging. I'd love to have something similar in GHC.
</p>
<p>
<a class="ext-link" href="http://www.radford.edu/~nokie/classes/320/std_lib_html/gnat-source_info.html"><span class="icon"></span>http://www.radford.edu/~nokie/classes/320/std_lib_html/gnat-source_info.html</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8220#changelog
http://ghc.haskell.org/trac/ghc/ticket/8244
http://ghc.haskell.org/trac/ghc/ticket/8244#8244: Removing the Cabal dependencyFri, 06 Sep 2013 15:17:10 GMTnh2<p>
GHC depends on cabal, which is so far has been problematic many times, for many reasons.
</p>
<p>
A few discussions include:
</p>
<ul><li><a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2013-September/108746.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-cafe/2013-September/108746.html</a>
</li><li><a class="ext-link" href="http://www.haskell.org/pipermail/ghc-devs/2013-March/000821.html"><span class="icon"></span>http://www.haskell.org/pipermail/ghc-devs/2013-March/000821.html</a>
</li></ul><p>
GHC uses only a very small part of Cabal, in these files:
</p>
<pre class="wiki">./compiler/ghci/Linker.lhs
./compiler/main/Packages.lhs
./compiler/main/PackageConfig.hs
./compiler/main/Finder.lhs
</pre><p>
plus 1 file for ghc-pkg: ./utils/ghc-pkg/Main.hs (see <a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2013-September/108750.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-cafe/2013-September/108750.html</a> for details).
</p>
<p>
It was proposed that either
</p>
<ul><li>the package format could be a plain specification without direct code dependencies
</li><li>the Cabal package could be split off into Cabal-the-build-system and a minimal part to describe the package DB to be shared by Cabal and GHC
</li></ul><p>
The Cabal part that is used is in only a few modules of Distribution.* while the remaining majority of the Cabal-the-library package is not used (e.g. none of Distribution.Simple.*).
</p>
<p>
Decoupling GHC and Cabal seems to be a public desire, yet there are some problems with these approaches. Let us discuss them in this ticket.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8244#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/8253
http://ghc.haskell.org/trac/ghc/ticket/8253#8253: example "Core syntax" is ancientSun, 08 Sep 2013 01:20:30 GMTrwbarton<p>
<a href="http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/options-debugging.html#idp39365504">User's guide section 4.19.5</a> has some funky "Core syntax" that (according to git blame) dates back to at least 2000, and probably longer ago than that. It could use an update.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8253#changelog
http://ghc.haskell.org/trac/ghc/ticket/8263
http://ghc.haskell.org/trac/ghc/ticket/8263#8263: allow duplicate deriving / standalone derivingTue, 10 Sep 2013 18:33:15 GMTaavogt<p>
I would like to avoid conditional compilation. Currently I need to write:
</p>
<pre class="wiki">#if MIN_VERSION_Cabal(1,18,0)
-- cabal 1.18 has these instances
#else
deriving instance Typeable Flag
#endif
</pre><p>
Would it be sane to have the deriving instance do nothing if the imported instance that clashes was also derived?
</p>
<p>
reifyInstances together with a fixed <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/8100" title="feature request: Standalone deriving using template haskell (closed: fixed)">#8100</a> could allow faking this feature.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8263#changelog
http://ghc.haskell.org/trac/ghc/ticket/8265
http://ghc.haskell.org/trac/ghc/ticket/8265#8265: getTokenStream fails for source using cppTue, 10 Sep 2013 19:46:29 GMTalanz<p>
Calling getTokenStream (or getRichTokenStream) on a module that has CPP directives fails as the lexer is given un-preprocessed source
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8265#changelog
http://ghc.haskell.org/trac/ghc/ticket/8290
http://ghc.haskell.org/trac/ghc/ticket/8290#8290: lookupSymbol API is unsafeSat, 14 Sep 2013 04:02:14 GMTezyang<p>
lookupSymbol is one of those functions that looks nice and innocuous on the tin, until you realize actually it doesn't actually do what you want, and seduces you into writing code that doesn't work on Mac OS X. Case in point, this recent test suite commit:
</p>
<pre class="wiki">commit 02d4958903e967b78fc3bbceddc2ce8ce33901c0
Author: Edward Z. Yang <ezyang@mit.edu>
Date: Fri Sep 13 20:52:57 2013 -0700
Properly provide leading underscore when necessary.
Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
</pre><p>
Yes, the API is "correct" in some sense, but from a portability sense, we really want the function to add the underscore itself.
</p>
<p>
If we change this particular function, we will probably break most dynamic loading code (including GHC's). We could also add a safe variant of the function. We just need to decide something to do.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8290#changelog
http://ghc.haskell.org/trac/ghc/ticket/8292
http://ghc.haskell.org/trac/ghc/ticket/8292#8292: linker_unload test doesn't work on WindowsSat, 14 Sep 2013 05:48:31 GMTezyang<p>
I fixed up the major issues but I am getting:
</p>
<pre class="wiki">"/c/Users/ezyang/Dev/ghc-dyn/inplace/bin/ghc-stage2.exe" -fforce-recomp -dcore-lint -dcmm-lint
-dno-debug-output -no-user-package-db -rtsopts -c Test.hs -v0
# -rtsopts causes a warning
"/c/Users/ezyang/Dev/ghc-dyn/inplace/bin/ghc-stage2.exe" -fforce-recomp -dcore-lint -dcmm-lint
-dno-debug-output -no-user-package-db linker_unload.c -o linker_unload -no-hs-main -optc-Werror
./linker_unload \Users\ezyang\Dev\ghc-dyn\libraries\base\dist-install\build/libHSbase-4.7.0.0.a
\Users\ezyang\Dev\ghc-dyn\libraries\ghc-prim\dist-install\build/libHSghc-prim-0.3.1.0.a \Users
\ezyang\Dev\ghc-dyn\libraries\integer-gmp\dist-install\build/libHSinteger-gmp-0.5.1.0.a
linker_unload.exe: \Users\ezyang\Dev\ghc-dyn\libraries\base\dist-install\build/libHSbase-4.7.0.
0.a: unknown symbol `_select'
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8292#changelog
http://ghc.haskell.org/trac/ghc/ticket/8293
http://ghc.haskell.org/trac/ghc/ticket/8293#8293: user001 spuriously fails if getGroupEntryForID correctly failsSat, 14 Sep 2013 05:58:42 GMTezyang<p>
In some cases, a user's current group ID can be a number for a non-existent group. While this usually indicates the system is misconfigured in some way, it can also occur inside chroots or other environments where the information in /etc/groups is not to be considered reliable. Unfortunately, the user001 has no way of telling that the failure is proper, and fails the test anyway. We ought to do something more robust.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8293#changelog
http://ghc.haskell.org/trac/ghc/ticket/8300
http://ghc.haskell.org/trac/ghc/ticket/8300#8300: split-objs doesn't split on LLVMSat, 14 Sep 2013 22:35:28 GMTrwbarton<p>
<tt>-split-objs</tt> is allowed with <tt>-fllvm</tt>, but it doesn't really do anything. E.g. in my perf-llvm build I have a <tt>libHSbase-4.7.0.0.a</tt> with <tt>Applicative__1.o</tt>, <tt>Arrow__1.o</tt> etc.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8300#changelog
http://ghc.haskell.org/trac/ghc/ticket/8304
http://ghc.haskell.org/trac/ghc/ticket/8304#8304: more lenient operator sections (RelaxedSections extension)Sun, 15 Sep 2013 23:00:08 GMTaavogt<p>
Some operator sections are rejected which could have some meaning.
</p>
<pre class="wiki">(a ++ b ++ ) could mean \x -> a ++ b ++ c
(++ a ++) could mean \x y -> x ++ a ++ y
</pre><p>
The attached quasiquoter implements this, but for various reasons it would be better if ghc supported this directly.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8304#changelog
http://ghc.haskell.org/trac/ghc/ticket/8308
http://ghc.haskell.org/trac/ghc/ticket/8308#8308: Resurrect ticky code for counting constructor arityMon, 16 Sep 2013 09:37:56 GMTjstolarek<p>
There is a dead piece of ticky profiling code that computes histograms of data constructor arities (including tuples) and size of vector returns. The function responsible is <tt>bumpHistogram</tt> in <a href="/trac/ghc/browser/ghc/compiler/codeGen/StgCmmTicky.hs">compiler/codeGen/StgCmmTicky.hs</a>, which masks the commented out function <tt>bumpHistogramE</tt>. We can improve ticky profiling by resurrecting this dead code. There are following things that need to be done:
</p>
<ol><li>Replace current no-op <tt>bumpHistogram</tt> with <tt>bumpHistogramE</tt>. Note that current implementation of <tt>bumpHistogramE</tt> computes constructor arity at runtime. This is unnecessary because we know arity at compile time so we can avoid runtime check by doing sth like this:
</li></ol><pre class="wiki">bumpHistogram lbl n = do
let offset = n `min` 8
emit (addToMem cLong
(cmmIndexExpr cLongWidth
(CmmLit (CmmLabel (mkRtsDataLabel lbl)))
(CmmReg (CmmInt (fromIntegral offset) cLongWidth)))
1)
</pre><p>
Note that <tt>mkRtsDataLabel</tt> function does not exist anymore but we should be able to replace that call with <tt>mkCmmDataLabel rtsPackageId lbl</tt> (speculation).
</p>
<ol start="2"><li>We need to declare arrays that will store histogram values. Declarations of variables used for storing ticky statistics are in <a href="/trac/ghc/browser/ghc/includes/stg/Ticky.h">includes/stg/Ticky.h</a>. We also need to initialize the declared array to contain only zeros.
</li></ol><ol start="3"><li>Having declared the arrays we need to fix printing of computed arities. This is done in <a href="/trac/ghc/browser/ghc/rts/Ticky.c">rts/Ticky.c</a>. Note that there is a lot of code that is commented out (<tt>/* krc: comment out some of this stuff temporarily */</tt>) or disabled with <tt>#if FALSE</tt> pragma. We need to resurect *some* of it. There is a <tt>PR_HST</tt> macro for printing one histogram entry. This seems bad. We should probably rework the part of code responsible for printing out results of historgams.
</li></ol><ol start="4"><li>Current code counts arities from 0 to 8. Everything above 8 is put into the same bin as 8. This magical 8 is spread all over the code. We should declare a constant that is visible both in Haskell sources (see <tt>bumpHistogram</tt> in 1.) and RTS files and have all code behave properly depending on that constant - we should have loops instead of statically printing 9 elements of histogram array.
</li></ol><ol start="5"><li>Some ticky functions that count arity histograms are not used. For example <tt>tickyReturnNewCon</tt> should probably be called by <tt>cgConApp</tt> like this:
</li></ol><pre class="wiki"> ; emit =<< fcode_init
; tickyReturnNewCon
; emitReturn [idInfoToAmode idinfo] }
</pre><p>
The above is a an outline, which should be fairly accurate, but unexpected things may show up along the way.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8308#changelog
http://ghc.haskell.org/trac/ghc/ticket/8311
http://ghc.haskell.org/trac/ghc/ticket/8311#8311: suboptimal code generated for even :: Int -> Bool by NCG (x86, x86_64)Mon, 16 Sep 2013 21:37:19 GMTrwbarton<p>
This appears to be the x86 assembly for a specialization for <tt>even :: Int -> Bool</tt> that's produced by a SPECIALISE pragma for <tt>(^) :: Int -> Int -> Int</tt> in GHC.Real. The relevant bit is offsets <tt>0x2c</tt> through <tt>0x3b</tt>.
</p>
<pre class="wiki">
0000000c <base_GHCziReal_evenzuzdseven1_info>:
c: 8b 45 00 mov 0x0(%ebp),%eax
f: c7 45 00 2c 00 00 00 movl $0x2c,0x0(%ebp)
12: R_386_32 .text
16: 89 c6 mov %eax,%esi
18: f7 c6 03 00 00 00 test $0x3,%esi
1e: 75 0c jne 2c <c8gO_info>
20: ff 26 jmp *(%esi)
22: 66 90 xchg %ax,%ax
24: 00 00 add %al,(%eax)
26: 00 00 add %al,(%eax)
28: 20 00 and %al,(%eax)
...
0000002c <c8gO_info>:
2c: b8 02 00 00 00 mov $0x2,%eax
31: 89 c1 mov %eax,%ecx
33: 8b 46 03 mov 0x3(%esi),%eax
36: 99 cltd
37: f7 f9 idiv %ecx
39: 85 d2 test %edx,%edx
3b: 75 0b jne 48 <c8gO_info+0x1c>
3d: be 02 00 00 00 mov $0x2,%esi
3e: R_386_32 ghczmprim_GHCziTypes_True_closure
42: 83 c5 04 add $0x4,%ebp
45: ff 65 00 jmp *0x0(%ebp)
48: be 01 00 00 00 mov $0x1,%esi
49: R_386_32 ghczmprim_GHCziTypes_False_closure
4d: 83 c5 04 add $0x4,%ebp
50: ff 65 00 jmp *0x0(%ebp)
</pre><p>
It would be much better to do a simple <tt>testb $0x1,0x3(%esi)</tt> in place of the first six instructions of <tt>c8gO_info</tt>.
</p>
<p>
The NCG generates similar code on x86_64.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8311#changelog
http://ghc.haskell.org/trac/ghc/ticket/8315
http://ghc.haskell.org/trac/ghc/ticket/8315#8315: Improve specialized Hoopl moduleTue, 17 Sep 2013 09:20:53 GMTjstolarek<p>
GHC uses Hoopl to perform some of the Cmm-to-Cmm optimization passes, but instead of relying directly on Hoopl library GHC uses its own specialized module (see <a href="/trac/ghc/browser/ghc/compiler/cmm/Hoopl/Dataflow.hs">compiler/cmm/Hoopl/Dataflow.hs</a>). Interface of that module, as well as its internal implementation can be improved. Right now interface places responsibility of maintaining some of the invariants on user. It also ignores differences between forward and backward analysis. <a class="ext-link" href="http://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup"><span class="icon"></span>This wiki page</a> gives full detail about proposed design changes.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8315#changelog
http://ghc.haskell.org/trac/ghc/ticket/8316
http://ghc.haskell.org/trac/ghc/ticket/8316#8316: GHCi debugger segfaults when trying force a certain variableTue, 17 Sep 2013 11:50:16 GMTguest<p>
The file Test.hs has following definitions:
</p>
<pre class="wiki">whnf :: a -> IO ()
whnf a = a `seq` (return ())
foo :: [Int]
foo = [1..]
</pre><p>
Calling ghci as:
</p>
<pre class="wiki">ghci Test.hs -ignore-dot-ghci
</pre><p>
and bebugging foo like this:
</p>
<pre class="wiki">*Main> :b foo
Breakpoint 0 activated at Test.hs:5:7-11
*Main> foo
Stopped at Test.hs:5:7-11
_result :: [Int] = _
[Test.hs:5:7-11] *Main> :p foo
foo = (_t1::[Int])
[Test.hs:5:7-11] *Main> whnf _t1
</pre><p>
results in this segault:
</p>
<pre class="wiki"><interactive>: internal error: TSO object entered!
(GHC version 7.6.3 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
[1] 5445 abort (core dumped) ghci Test.hs -ignore-dot-ghci
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8316#changelog
http://ghc.haskell.org/trac/ghc/ticket/8317
http://ghc.haskell.org/trac/ghc/ticket/8317#8317: Optimize tagToEnum# at Core levelTue, 17 Sep 2013 12:31:49 GMTjstolarek<p>
Old comparison primops that returned Bool were implemented by inserting call to <tt>tagToEnum#</tt> in the code generator. This call to <tt>tagToEnum#</tt> was later optimized away by a special case in the code geenrator (see <a href="/trac/ghc/browser/ghc/compiler/codeGen/StgCmmExpr.hs">compiler/codeGen/StgCmmExpr.hs</a>, Note [case on bool])). Now that we have new comparison primops (see <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/6135" title="feature request: Unboxed Booleans (closed: fixed)">#6135</a>) we no longer insert <tt>tagToEnum#</tt> in the code generator - all uses of <tt>tagToEnum#</tt> come from explicit calls in a source program. But we still have that special case in the code generator to optimize away <tt>tagToEnum#</tt>. We should drop that special case in the code generator and handle scrutinizing of <tt>tagToEnum#</tt> at the Core level by:
</p>
<ol><li>removing call to <tt>tagToEnum#</tt> in the scrutinee
</li><li>adding calls to <tt>dataToTag#</tt> in case branches
</li><li>constant-folding inserted <tt>dataToTag#</tt>
</li></ol><p>
Here is an example. This Haskell code:
</p>
<pre class="wiki">if tagToEnum# (a ># b)
then E1
else E2
</pre><p>
will be translated to this Core:
</p>
<pre class="wiki">case tagToEnum# (a ># b) of
True -> E1
False -> E2
</pre><p>
and optimized like this:
</p>
<pre class="wiki">case a ># b of
dataToTag# True -> E1
dataToTag# False -> E2
</pre><p>
====>
</p>
<pre class="wiki">case a ># b of
1 -> E1
0 -> E2
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8317#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/8319
http://ghc.haskell.org/trac/ghc/ticket/8319#8319: Simplifier ticks exhausted (need -fsimpl-tick-factor=955)Tue, 17 Sep 2013 16:05:34 GMTruudkoot<p>
Attached file needs a rather high simpl-tick-factor (955) in order to compile.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8319#changelog
http://ghc.haskell.org/trac/ghc/ticket/8325
http://ghc.haskell.org/trac/ghc/ticket/8325#8325: Pattern guards in anonymous functionsWed, 18 Sep 2013 02:53:34 GMTmcollis<p>
In the course of a project, I had an idea that would allow less cumbersome use of cases in anonymous functions. Here's a simple example of what I'm proposing:
</p>
<pre class="wiki">
(\x y | x > y -> x
| otherwise -> something else)
</pre><p>
Currently, the only way to accomplish this is with if() then ... else syntax or the use of the MultiWayIf and LambdaCase extensions. The syntax I've proposed here matches with existing anonymous function syntax and doesn't conflict with any other GHC syntax. This would greatly improve the readability of complex anonymous functions.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8325#changelog
http://ghc.haskell.org/trac/ghc/ticket/8326
http://ghc.haskell.org/trac/ghc/ticket/8326#8326: Place heap checks common in case alternatives before the caseWed, 18 Sep 2013 11:58:16 GMTjstolarek<p>
We would like to have functions that check whether an <tt>Int#</tt> is a valid tag to represent <tt>Bool</tt> (see Note [Optimizing isTrue#] in ghc-prim):
</p>
<pre class="wiki">isTrue# :: Int# -> Bool
isTrue# 1# = True
isTrue# _ = False
isFalse# :: Int# -> Bool
isFalse# 0# = True
isFalse# _ = False
</pre><p>
We could use them with comparison primops like this:
</p>
<pre class="wiki">f :: Int# -> Int
f x | isTrue# (x ># 0#) = I# x
| otherwise = -(I# x)
</pre><p>
<tt>isTrue#</tt> is optimized away at the Core level:
</p>
<pre class="wiki">A.f =
\ (x_aqM :: GHC.Prim.Int#) ->
case GHC.Prim.># x_aqM 0 of _ {
__DEFAULT -> GHC.Types.I# (GHC.Prim.negateInt# x_aqM);
1 -> GHC.Types.I# x_aqM
}
</pre><p>
but the code genrator produces very bad Cmm code, because it pushes heap checks into case alternatives:
</p>
<pre class="wiki"> {offset
cFd: // stack check
if ((Sp + -16) < SpLim) goto cFr; else goto cFs;
cFr: // not enough place on the stack, call GC
R2 = R2;
R1 = A.f_closure;
call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8;
cFs: // scrutinize (x ># 0#)
_sEU::I64 = R2;
_sEV::I64 = %MO_S_Gt_W64(R2, 0);
if (_sEV::I64 != 1) goto cFg; else goto cFo;
cFg: // False branch
Hp = Hp + 16;
if (Hp > HpLim) goto cFy; else goto cFx;
cFy: // not enough heap, call GC
HpAlloc = 16;
I64[Sp - 16] = cFf;
R1 = _sEV::I64;
I64[Sp - 8] = _sEU::I64;
Sp = Sp - 16;
call stg_gc_unbx_r1(R1) returns to cFf, args: 8, res: 8, upd: 8;
cFf: // re-do the False branch
_sEU::I64 = I64[Sp + 8];
Sp = Sp + 16;
_sEV::I64 = R1;
goto cFg;
cFx: // RHS of False branch
I64[Hp - 8] = GHC.Types.I#_con_info;
I64[Hp] = -_sEU::I64;
R1 = Hp - 7;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
cFo: // True branch
Hp = Hp + 16;
if (Hp > HpLim) goto cFv; else goto cFu;
cFv: // not enough heap, call GC
HpAlloc = 16;
I64[Sp - 16] = cFn;
R1 = _sEV::I64;
I64[Sp - 8] = _sEU::I64;
Sp = Sp - 16;
call stg_gc_unbx_r1(R1) returns to cFn, args: 8, res: 8, upd: 8;
cFn: // re-do the True branch
_sEU::I64 = I64[Sp + 8];
Sp = Sp + 16;
_sEV::I64 = R1;
goto cFo;
cFu: // RHS of True branch
I64[Hp - 8] = GHC.Types.I#_con_info;
I64[Hp] = _sEU::I64;
R1 = Hp - 7;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
}
</pre><p>
This results in average 2.5% increase in binary size. By contrast, if we use <tt>tagToEnum#</tt> instead of <tt>isTrue#</tt> heap check will be placed before <tt>case</tt> expression and the code will be significantly shorter (this is done by a special case-on-bool optimization in the code generator - see <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/8317" title="task: Optimize tagToEnum# at Core level (new)">#8317</a>). What we would like to do here is:
</p>
<ol><li>compile case alternatives without placing heap checks inside them
</li><li>each compiled alternative should return amount of heap it needs to allocate
</li><li>code generator inspects amounts of heap needed by each alternative and either adds heap checks in alternatives or puts a single check before the case expression.
</li></ol><p>
Getting this right might be a bit tricky.
</p>
<ol><li>if all branches allocate some heap then we can just put a common heap check before the case. Note that we must allocate the higgest amount required by any of the alternatives and then alternatives that use less heap must retract the heap pointer accordingly.
</li><li>if we have two alternatives, one of which allocates heap and the other does not, we should place the heap check only in the alternative that allocates the stack. This will solve <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1498" title="bug: Optimisation: eliminate unnecessary heap check in recursive function (new)">#1498</a>.
</li><li>it is not clear to me what to do if we have combination of the above (more than one branch that allocates heap and at least one branch that does not). If we place heap check before the <tt>case</tt> expression we lose optimization of recursive functions and face the problem described in <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1498" title="bug: Optimisation: eliminate unnecessary heap check in recursive function (new)">#1498</a>. If we push heap checks into branches that allocate heap then we get code duplication, i.e. the problem that we're addressing in this ticket. I guess the only way to make correct decission here is to try different aproaches and measure their performance.
</li></ol><p>
This ticket is mentioned <a class="ext-link" href="http://ghc.haskell.org/trac/ghc/wiki/PrimBool#Implementationdetails"><span class="icon"></span>on this wiki page</a> and in the source code in Note [Optimizing isTrue#] in ghc-prim. Once this ticket is resolved we need to update these places accordingly.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8326#changelog
http://ghc.haskell.org/trac/ghc/ticket/8327
http://ghc.haskell.org/trac/ghc/ticket/8327#8327: Cmm sinking does not eliminate dead code in loopsWed, 18 Sep 2013 13:18:37 GMTjstolarek<p>
Cmm code shown in <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/8326" title="task: Place heap checks common in case alternatives before the case (new)">#8326</a> is suboptimal. For this Haskell code:
</p>
<pre class="wiki">isTrue# :: Int# -> Bool
isTrue# 1# = True
isTrue# _ = False
f :: Int# -> Int
f x | isTrue# (x ># 0#) = I# x
| otherwise = -(I# x)
</pre><p>
we get Cmm that contains dead code in a loop:
</p>
<pre class="wiki"> cFg: // False branch
Hp = Hp + 16;
if (Hp > HpLim) goto cFy; else goto cFx;
cFy: // not enough heap, call GC
HpAlloc = 16;
I64[Sp - 16] = cFf;
R1 = _sEV::I64;
I64[Sp - 8] = _sEU::I64;
Sp = Sp - 16;
call stg_gc_unbx_r1(R1) returns to cFf, args: 8, res: 8, upd: 8;
cFf: // re-do the False branch
_sEU::I64 = I64[Sp + 8];
Sp = Sp + 16;
_sEV::I64 = R1;
goto cFg;
cFx: // RHS of False branch
I64[Hp - 8] = GHC.Types.I#_con_info;
I64[Hp] = -_sEU::I64;
R1 = Hp - 7;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
</pre><p>
Notice that <tt>_sEV</tt> is dead - we should optimize it away. This is a known deficiency in the Cmm sinking pass (i.e. it does not work for loops). I'm putting this on Trac so we have this documented.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8327#changelog
http://ghc.haskell.org/trac/ghc/ticket/8335
http://ghc.haskell.org/trac/ghc/ticket/8335#8335: Create more specialized entries to GCFri, 20 Sep 2013 11:24:55 GMTjstolarek<p>
Consider this Cmm code (taken from <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/8326" title="task: Place heap checks common in case alternatives before the case (new)">#8326</a>):
</p>
<pre class="wiki"> {offset
cFd: // stack check
if ((Sp + -16) < SpLim) goto cFr; else goto cFs;
cFr: // not enough place on the stack, call GC
R2 = R2;
R1 = A.f_closure;
call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8;
cFs: // scrutinize (x ># 0#)
_sEU::I64 = R2;
_sEV::I64 = %MO_S_Gt_W64(R2, 0);
if (_sEV::I64 != 1) goto cFg; else goto cFo;
cFg: // False branch
Hp = Hp + 16;
if (Hp > HpLim) goto cFy; else goto cFx;
cFy: // not enough heap, call GC
HpAlloc = 16;
I64[Sp - 16] = cFf;
R1 = _sEV::I64;
I64[Sp - 8] = _sEU::I64;
Sp = Sp - 16;
call stg_gc_unbx_r1(R1) returns to cFf, args: 8, res: 8, upd: 8;
cFf: // re-do the False branch
_sEU::I64 = I64[Sp + 8];
Sp = Sp + 16;
_sEV::I64 = R1;
goto cFg;
cFx: // RHS of False branch
I64[Hp - 8] = GHC.Types.I#_con_info;
I64[Hp] = -_sEU::I64;
R1 = Hp - 7;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
cFo: // True branch
Hp = Hp + 16;
if (Hp > HpLim) goto cFv; else goto cFu;
cFv: // not enough heap, call GC
HpAlloc = 16;
I64[Sp - 16] = cFn;
R1 = _sEV::I64;
I64[Sp - 8] = _sEU::I64;
Sp = Sp - 16;
call stg_gc_unbx_r1(R1) returns to cFn, args: 8, res: 8, upd: 8;
cFn: // re-do the True branch
_sEU::I64 = I64[Sp + 8];
Sp = Sp + 16;
_sEV::I64 = R1;
goto cFo;
cFu: // RHS of True branch
I64[Hp - 8] = GHC.Types.I#_con_info;
I64[Hp] = _sEU::I64;
R1 = Hp - 7;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
}
</pre><p>
We perform two different calls to garbage collection here. Calling GC after making initial stack check obviously can't use any stack, so we pass parameter to GC in regsiters:
</p>
<pre class="wiki">R2 = R2;
R1 = A.f_closure;
call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8;
</pre><p>
But in the calls that are made later on inside the function we do put some parameters on the stack, thus increasing stack usage:
</p>
<pre class="wiki">cFv: // not enough heap, call GC
HpAlloc = 16;
I64[Sp - 16] = cFn;
R1 = _sEV::I64;
I64[Sp - 8] = _sEU::I64;
Sp = Sp - 16;
call stg_gc_unbx_r1(R1) returns to cFn, args: 8, res: 8, upd: 8;
</pre><p>
If we had more specialized entries to GC that would allow us to pass parameters in registers (or in some fixed memory location associated with TCO?) then this function would not require any stack at all. Note that there is a separate issue here - <tt>_sEV</tt> variable is in fact dead and should be eliminated (see <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/8327" title="bug: Cmm sinking does not eliminate dead code in loops (new)">#8327</a>).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8335#changelog
http://ghc.haskell.org/trac/ghc/ticket/8336
http://ghc.haskell.org/trac/ghc/ticket/8336#8336: Sinking pass could optimize some assignments betterFri, 20 Sep 2013 11:43:59 GMTjstolarek<p>
Compiling this program:
</p>
<pre class="wiki">{-# LANGUAGE BangPatterns, MagicHash, CPP #-}
{-# OPTIONS_GHC -O2 -funbox-strict-fields #-}
module HashStr where
import Foreign.C
import GHC.Exts
import Data.Word
#define hASH_TBL_SIZE 4091
hashStr :: Ptr Word8 -> Int -> Int
-- use the Addr to produce a hash value between 0 & m (inclusive)
hashStr (Ptr a#) (I# len#) = loop 0# 0#
where
loop h n | n GHC.Exts.==# len# = I# h
| otherwise = loop h2 (n GHC.Exts.+# 1#)
where !c = ord# (indexCharOffAddr# a# n)
!h2 = (c GHC.Exts.+# (h GHC.Exts.*# 128#)) `remInt#`
hASH_TBL_SIZE#
</pre><p>
produces following Cmm code for <tt>hashStr</tt> function:
</p>
<pre class="wiki">{offset
cut:
goto cux;
cux:
_stC::I64 = R3;
_stB::I64 = R2;
_stF::I64 = 0;
_stE::I64 = 0;
goto stD;
stD:
if (_stF::I64 == _stC::I64) goto cuH; else goto cuI;
cuH:
R1 = _stE::I64;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
cuI:
_stM::I64 = %MO_S_Rem_W64(%MO_UU_Conv_W8_W64(I8[_stB::I64 + _stF::I64]) + (_stE::I64 << 7),
4091);
_stF::I64 = _stF::I64 + 1;
_stE::I64 = _stM::I64;
goto stD;
}
</pre><p>
The problem here is that three last assignments:
</p>
<pre class="wiki">_stM::I64 = %MO_S_Rem_W64(%MO_UU_Conv_W8_W64(I8[_stB::I64 + _stF::I64]) + (_stE::I64 << 7), 4091);
_stF::I64 = _stF::I64 + 1;
_stE::I64 = _stM::I64;
</pre><p>
could be optimized as:
</p>
<pre class="wiki">_stE::I64 = %MO_S_Rem_W64(%MO_UU_Conv_W8_W64(I8[_stB::I64 + _stF::I64]) + (_stE::I64 << 7), 4091);
_stF::I64 = _stF::I64 + 1;
</pre><p>
We should improve sinking pass so that it can optimize such cases. See Note [dependent assignments] in CmmSink.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8336#changelog
http://ghc.haskell.org/trac/ghc/ticket/8338
http://ghc.haskell.org/trac/ghc/ticket/8338#8338: Incoherent instances without -XIncoherentInstancesFri, 20 Sep 2013 20:34:00 GMTgoldfire<p>
Consider the following 4 modules:
</p>
<pre class="wiki">{-# LANGUAGE GADTs #-}
module A where
data One = One
data ShowInstFor a = Show a => MkSIF
incoherent :: ShowInstFor One -> ShowInstFor One -> String
incoherent MkSIF MkSIF = show One
</pre><pre class="wiki">module B where
import A
instance Show One where
show _ = "from module B"
fromB :: ShowInstFor One
fromB = MkSIF
</pre><pre class="wiki">module C where
import A
instance Show One where
show _ = "from module C"
fromC :: ShowInstFor One
fromC = MkSIF
</pre><pre class="wiki">module D where
import A
import B
import C
oops1 = incoherent fromB fromC
oops2 = incoherent fromC fromB
</pre><p>
According to ghci, <tt>oops1</tt> is <tt>"from moduleB"</tt> and <tt>oops2</tt> is <tt>"from module C"</tt>. This seems bad.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8338#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/8347
http://ghc.haskell.org/trac/ghc/ticket/8347#8347: Add a Strict LANGUAGE pragmaMon, 23 Sep 2013 15:46:48 GMTtibbe<p>
A <tt>Strict</tt> <tt>LANGUAGE</tt> pragma would allow us to experiment with writing in a strict sub-language. Since this pragma works on a per module basis, it needs to be modular. I propose the following semantics:
</p>
<ul><li>Patterns are strict at the top-level, as if they had a top-level bang, unless an explicit ~ is used to make the pattern lazy.
</li><li>Functions evaluate their parameters to WHNF.
</li><li>Data type fields are strict (as if they had a bang-pattern).
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8347#changelog
http://ghc.haskell.org/trac/ghc/ticket/8353
http://ghc.haskell.org/trac/ghc/ticket/8353#8353: Easy way to defer type errorsTue, 24 Sep 2013 15:55:45 GMTgoldfire<p>
A number of comments I've heard recently have focused on the joy of <tt>-fdefer-type-errors</tt>, especially for newcomers to Haskell. However, in GHCi, one has to
</p>
<ol><li>be aware that <tt>-fdefer-type-errors</tt> exists
</li><li>know the <tt>:set ...</tt> syntax to turn it on, and then
</li><li>is stuck with this setting on until they turn it off
</li></ol><p>
Instead, I propose new <tt>:load!</tt> and <tt>:reload!</tt> commands (abbreviated to <tt>:l!</tt> and <tt>:r!</tt>) which turn on <tt>-fdefer-type-errors</tt> just for that one command. When a load or reload fails, the error message could suggest these alternate forms.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8353#changelog
http://ghc.haskell.org/trac/ghc/ticket/8354
http://ghc.haskell.org/trac/ghc/ticket/8354#8354: Add INLINE (or at least INLINABLE) pragmas for methods of Ord in ghc-primTue, 24 Sep 2013 17:26:46 GMTguest<p>
Self-explanatory. Eq already has INLINE on (==) and (/=), and it'd be nice to have it on Ord so that SPECIALIZE pragmas on its methods in user code can fire.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8354#changelog
http://ghc.haskell.org/trac/ghc/ticket/8363
http://ghc.haskell.org/trac/ghc/ticket/8363#8363: Order matters for unused import warnings when reexporting identifiersThu, 26 Sep 2013 12:00:51 GMTbergmark<p>
Import order seem to change whether unused import warnings trigger when a module re-exports an identifier, with another module importing it and another module exporting the same identifier.
</p>
<p>
Reproduction:
</p>
<pre class="wiki">module Foo ( (<$>) , g ) where
import Control.Applicative
g :: Int
g = 1
</pre><pre class="wiki">module Main where
import Control.Applicative
import Foo
main :: IO ()
main = print =<< ((+2) <$> return g)
</pre><pre class="wiki">$ ghc -fwarn-unused-imports Main.hs
[1 of 2] Compiling Foo ( Foo.hs, Foo.o )
[2 of 2] Compiling Main ( Main.hs, Main.o )
Linking Main ...
</pre><p>
If Main is not using <tt>g</tt> then this gives a warning that the import of <tt>Foo</tt> is redundant.
</p>
<p>
If we switch the order of the imports we do get the warning:
</p>
<pre class="wiki">module Main where
import Foo
import Control.Applicative
main :: IO ()
main = print =<< ((+2) <$> return g)
</pre><pre class="wiki">> ghc -fwarn-unused-imports Main.hs
[1 of 2] Compiling Foo ( Foo.hs, Foo.o )
[2 of 2] Compiling Main ( Main.hs, Main.o )
Main.hs:4:1:
Warning: The import of `Control.Applicative' is redundant
except perhaps to import instances from `Control.Applicative'
To import instances alone, use: import Control.Applicative()
Linking Main ...
</pre><p>
I expected both versions of Main to produce the same warning.
Tested on GHC 7.7.20130824 and 7.4.2.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8363#changelog
http://ghc.haskell.org/trac/ghc/ticket/8372
http://ghc.haskell.org/trac/ghc/ticket/8372#8372: enable -dcmm-lint by default for .cmm input filesFri, 27 Sep 2013 22:14:36 GMTrwbarton<p>
I'm finding it's quite easy to write <tt>.cmm</tt> files with subtle errors that cause ghc to emit code that wasn't what I wanted! For example, I wrote a comparison between two arguments of different integer sizes and the code generator picked the wrong size. After tracking down the bug, I tried <tt>-dcmm-lint</tt> and it caught my error right away.
</p>
<p>
It makes sense not to have <tt>-dcmm-lint</tt> enabled by default for Cmm produced from Stg, but I've seen here on the GHC wiki that <tt>-dcmm-lint</tt> is advised for hand-written <tt>.cmm</tt> files. But <tt>integer-gmp</tt>, and probably many other packages, don't build <tt>.cmm</tt> files with <tt>-dcmm-lint</tt>. Is there a reason we can't/shouldn't just make it the default?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8372#changelog
http://ghc.haskell.org/trac/ghc/ticket/8378
http://ghc.haskell.org/trac/ghc/ticket/8378#8378: Cross-compiling from x86_64-unknown-linux-gnu to x86_64-sun-solaris2 with mkGmpConstants workaround fails to build objects for integer-gmpSat, 28 Sep 2013 16:20:51 GMTAlainODea<p>
Here is the script I used to get build dependencies:
</p>
<pre class="wiki">sudo apt-get update
sudo apt-get install --assume-yes ghc libncurses5-dev \
mesa-common-dev freeglut3-dev libedit-dev
cabal install happy alex haddock
</pre><p>
Here is the build bootstrap script I am using on a clean Ubuntu 13.04 install:
</p>
<pre class="wiki">#!/bin/bash
export TARGET=x86_64-sun-solaris2.11
export PREFIX=$HOME/Documents/gcc/cross/$TARGET
export SYSROOT=$PREFIX/sysroot
export PATH=$PATH:$PREFIX/bin
export GCC=$PREFIX/bin/$TARGET-gcc
export LD=$PREFIX/bin/$TARGET-ld
export NM=$PREFIX/bin/$TARGET-nm
export OBJDUMP=$PREFIX/bin/$TARGET-objdump
git clone git://github.com/ghc/ghc
pushd ghc
echo "Stage1Only = YES" >> mk/build.mk
cp mk/build.mk{.sample,}
./sync-all --no-dph get
perl boot
patch -d libraries/haskeline/ -p1 < \
../ghc-patches/0001-Include-termios.h-for-solaris2-host.-Fixes-8366.patch
cp $SYSROOT/opt/local/include/gmp.h libraries/integer-gmp/gmp/
./configure \
--host=x86_64-unknown-linux-gnu \
--build=x86_64-unknown-linux-gnu \
--target=x86_64-sun-solaris2 \
--with-gcc=$GCC \
--with-ld=$LD \
--with-nm=$NM \
--with-objdump=$OBJDUMP
make
# will fail with failure to run mkGmpDerivedConstants
scp inplace/lib/bin/mkGmpDerivedConstants root@ns2:.
ssh root@ns2 "./mkGmpDerivedConstants" > \
libraries/integer-gmp/mkGmpDerivedConstants/dist/GmpDerivedConstants.h
make
cat << __EOF__ >> libraries/base/include/HsBaseConfig.h
#define HTYPE_DOUBLE Double
#define HTYPE_FLOAT Float
__EOF__
make
#make -j $(nproc)
popd
</pre><p>
The log of the run is attached. It is too large for the ticket body and apparently too large for Gist as well.
</p>
<p>
Somewhere along the way the build forgets integer-gmp and no objects are built for it.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8378#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/8388
http://ghc.haskell.org/trac/ghc/ticket/8388#8388: forall on non-* typesMon, 30 Sep 2013 19:06:21 GMTmonoidal<p>
This code
</p>
<pre class="wiki">{-# LANGUAGE RankNTypes, ImpredicativeTypes #-}
x = Nothing :: (forall a. Maybe) Int
</pre><p>
gives
</p>
<pre class="wiki"> Couldn't match type `Maybe' with `forall a. Maybe'
Expected type: forall a. Maybe Int
Actual type: Maybe Int
</pre><p>
which does not seem correct. There are two options:
</p>
<p>
Option A: We allow this.
</p>
<p>
Option B: We reject this as ill-kinded and allow <tt>forall a. T</tt> only when <tt>T</tt> has kind <tt>*</tt>. I prefer this option; in theory this can break existing code, but I am not aware of any code that uses forall on non-* type (please correct me if I'm wrong), and e.g. this means <tt>forall a. a</tt> inhabits every kind, for example <tt>Bool</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8388#changelog
http://ghc.haskell.org/trac/ghc/ticket/8399
http://ghc.haskell.org/trac/ghc/ticket/8399#8399: Of Bird tacks and non-blank blank linesWed, 02 Oct 2013 18:42:22 GMTtinctorius<pre class="wiki">> main :: IO ()
\begin{code}
\end{code}
> main = print "Hello world!"
</pre><p>
According to the Haskell 1.2 report, code in Bird tacks must be hugged by blank lines (or file borders), to catch unintended use. The above should be _rejected_ during the unlit phase.
</p>
<p>
However, because GHC's <tt>unlit</tt> thinks lines with <tt>\begin{code}</tt> and <tt>\end{code}</tt> are blank lines, the above is _accepted_. I believe this is an error.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8399#changelog
http://ghc.haskell.org/trac/ghc/ticket/8403
http://ghc.haskell.org/trac/ghc/ticket/8403#8403: Pretty-printing of long typesThu, 03 Oct 2013 14:11:33 GMTmonoidal<p>
Low priority, but this ghci output could be more packed.
</p>
<pre class="wiki">λ> :t (,,,,,,,,,,,,,,,,,,,,,,,)
(,,,,,,,,,,,,,,,,,,,,,,,)
:: a
-> b
-> c
-> d
-> e
-> f
-> g
-> h
-> i
-> j
-> k
-> l
-> m
-> n
-> o
-> p
-> q
-> r
-> s
-> t
-> u
-> v
-> w
-> x
-> (a,
b,
c,
d,
e,
f,
g,
h,
i,
j,
k,
l,
m,
n,
o,
p,
q,
r,
s,
t,
u,
v,
w,
x)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8403#changelog
http://ghc.haskell.org/trac/ghc/ticket/8404
http://ghc.haskell.org/trac/ghc/ticket/8404#8404: Default to turning on architecture specific optimizations in the codegenThu, 03 Oct 2013 16:09:04 GMTtibbe<p>
LLVM defaults to turning on whatever architecture specific optimizations are supported on the user's machine (e.g. <tt>-msse4.2</tt>). This makes programs run faster during testing and generally gives users a better perception of the compiler. If the user wants to compile for some more portable subset (e.g. when cross-compiling) he/she adds <tt>-march</tt>, <tt>-mcpu</tt>, etc flags on the command line.
</p>
<p>
To implement this we'd have to detect what CPU type is used etc and initialize our <tt>DynFlags</tt> based on that.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8404#changelog
http://ghc.haskell.org/trac/ghc/ticket/8414
http://ghc.haskell.org/trac/ghc/ticket/8414#8414: ghc-pkg prevents dynamic library only packagesSat, 05 Oct 2013 16:32:41 GMTAndreasVoellmy<p>
GHC supports compiling Haskell libraries as dynamic libraries and building executables against dynamic libraries. GHCi seems to support loading modules from dynamic libraries, too. So it would seem that it should be possible to have packages that only include dynamic libraries, omitting the .a and .o files typically generated.
</p>
<p>
cabal-install allows building dynamic libraries only, for example with the command "cabal install --disable-library-vanilla --enable-shared --disable-library-profiling". However, ghc-pkg register refuses to install the package without the .a files present. This seems to be a bug with ghc-pkg.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8414#changelog
http://ghc.haskell.org/trac/ghc/ticket/8420
http://ghc.haskell.org/trac/ghc/ticket/8420#8420: Spurious dynamic library dependenciesTue, 08 Oct 2013 01:02:19 GMTAndreasVoellmy<p>
It should be possible to have an executable A that depends on dynamic library B which in turn depends on dynamic library C, without A directly depending on C.
<tt> A --> B --> C </tt>
Unfortunately, GHC 7.6.3 does not seem to allow this. Instead it copies the dependencies of B to dependencies of A, so that we get
<tt> A -> B,C and B --> C </tt>
</p>
<p>
This is unfortunately, because running A will cause the loader to locate C based on the rpaths (assuming we are using rpaths to locate dynamic libraries), whereas only B should know how to get to C from B.
</p>
<p>
The problem seems to be that ghc copies all the library dependencies of B (presumably from the package specification of B) as library dependencies of the A.
</p>
<p>
I verified the problem in GHC 7.6.3, but haven't tried in HEAD yet.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8420#changelog
http://ghc.haskell.org/trac/ghc/ticket/8424
http://ghc.haskell.org/trac/ghc/ticket/8424#8424: quasi-quotes have carriage returns on WindowsWed, 09 Oct 2013 03:09:28 GMTGregWeber<p>
A Windows user rerported using Data.Text.IO.writeFile to write out quasi-quoted text.
</p>
<p>
writeFile automatically translates '\r' to "\r\n", so the user ended up writing out "\r\r\n" to a file.
</p>
<p>
Haskell seems to be adopting the policy or removing '\r' from Haskell land. Is there any reason why quasi-quotes should not automatically strip carriage returns?
</p>
<p>
I asked this question on ghc-users and there was no response.
</p>
<p>
I am willing to make this fix if it is deemed appropriate.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8424#changelog
http://ghc.haskell.org/trac/ghc/ticket/8441
http://ghc.haskell.org/trac/ghc/ticket/8441#8441: Allow family instances in an hs-boot fileSun, 13 Oct 2013 03:28:36 GMTgoldfire<p>
Compiling an .hs-boot file with a data instance leads to this error:
</p>
<pre class="wiki"> Illegal family instance in hs-boot file
</pre><p>
Yet, data instances make good sense in an hs-boot file, in case another module wants to access a constructor declared in the instance.
</p>
<p>
Furthermore, it may sometimes be desirable to allow type family instances in a hs-boot file, as well, in case some including modules need the instance for type simplification.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8441#changelog
http://ghc.haskell.org/trac/ghc/ticket/8473
http://ghc.haskell.org/trac/ghc/ticket/8473#8473: Generate table of cost-centre numbers with source locationsWed, 23 Oct 2013 18:04:14 GMTlars_e_krueger<p>
.prof files contain a cost centre number, which I assume is cc_key from CostCentre.lhs. It would be immensely helpful if the compiler creates a simpe table. This way, one could look up the number in .prof, check the table and the exact source location. It would also help with <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/7105" title="feature request: Better names for derived SCCs of instances (new)">#7105</a>, I think.
</p>
<p>
Suggestion for the format:
</p>
<pre class="wiki">no. file begin end
1 main.hs 127:7 128:14
</pre><p>
Meaning: Cost centre 1 is in file main.hs, begins at line 127, character 7 and ends at line 128, character 14.
</p>
<p>
If somebody points me in the right direction, and the whole thing is not too complicated, I can try my hand at implementing it myself.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8473#changelog
http://ghc.haskell.org/trac/ghc/ticket/8477
http://ghc.haskell.org/trac/ghc/ticket/8477#8477: Allow inferring ambiguous typesFri, 25 Oct 2013 19:35:17 GMTaavogt<p>
Previous versions of ghc could infer types that are potentially ambiguous. This allowed things like <a class="ext-link" href="http://okmij.org/ftp/Haskell/TypeLambdaVal.hs"><span class="icon"></span>http://okmij.org/ftp/Haskell/TypeLambdaVal.hs</a> or assigning keyword args functions to variables <a class="ext-link" href="http://code.haskell.org/~aavogt/HList/docs/HList/Data-HList-Keyword.html"><span class="icon"></span>http://code.haskell.org/~aavogt/HList/docs/HList/Data-HList-Keyword.html</a>. Presently (7.6 and 7.7), you need to write a type signature yourself to allow such definitions, which in these situations doubles the amount of code to write. For the keyword case, the workaround is to use the kw function to apply the keyword function instead of ordinary function application.
</p>
<p>
More related discussion <a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-users/2013-October/024404.html"><span class="icon"></span>http://www.haskell.org/pipermail/glasgow-haskell-users/2013-October/024404.html</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8477#changelog
http://ghc.haskell.org/trac/ghc/ticket/8487
http://ghc.haskell.org/trac/ghc/ticket/8487#8487: Debugger confuses variablesWed, 30 Oct 2013 08:34:10 GMTedsko<p>
Consider the following example:
</p>
<pre class="wiki">import Control.Exception
f = do
ma <- try $ evaluate a
case ma of
Right str -> return a
Left err -> return $ show (err :: SomeException)
where
a :: String
a = error "hi"
</pre><p>
Load into ghci, set a breakpoint on the 5th line, then run f:
</p>
<pre class="wiki">:break 5
f
</pre><p>
You will get
</p>
<pre class="wiki">Stopped at Ex.hs:(5,3)-(7,53)
_result :: IO String = _
a :: Either SomeException String = Left _
</pre><p>
This doesn't make sense. <tt>a</tt> has type <tt>String</tt>; it is <tt>ma</tt> that has type <tt>Either SomeException String</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8487#changelog
http://ghc.haskell.org/trac/ghc/ticket/8488
http://ghc.haskell.org/trac/ghc/ticket/8488#8488: Annotations should not distinguish type and valueWed, 30 Oct 2013 09:01:50 GMTsimonpj<p>
In <tt>HsDecls</tt> we have
</p>
<pre class="wiki">data AnnDecl name = HsAnnotation (AnnProvenance name) (Located (HsExpr name))
data AnnProvenance name = ValueAnnProvenance name
| TypeAnnProvenance name
| ModuleAnnProvenance
</pre><p>
And there's now a similar 3-way distinction in Template Haskell <tt>Syntax</tt>:
</p>
<pre class="wiki">data AnnTarget = ModuleAnnotation
| TypeAnnotation Name
| ValueAnnotation Name
</pre><p>
But there's really no need to distinguish between <tt>TypeAnnProvenance</tt> and <tt>ValueAnnProvenance</tt> (and similarly in the TH vesrion) because the namespace on the <tt>Name</tt> makes that distinction. So the current story is redundant, and hence has silly case where you have a <tt>ValueAnnProvenance</tt> on a type constructor.
</p>
<p>
Better to collapse the two. I'm making this a ticket so that people can comment. I hope that Gergely may be able to do it as part of his TH/annotation work.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8488#changelog
http://ghc.haskell.org/trac/ghc/ticket/8494
http://ghc.haskell.org/trac/ghc/ticket/8494#8494: Warn if a pattern guard obviates all othersFri, 01 Nov 2013 05:06:14 GMTJohnWiegley<p>
The following code, when compiled with <tt>-Wall</tt>, gives no warnings:
</p>
<pre class="wiki">module Main where
main :: IO ()
main = print $ foo (10 :: Int)
where
foo x
| True = (20 :: Int)
| x == 10 = (30 :: Int)
</pre><p>
I would expect that since the pattern guard <tt>| True</tt> obviates the following guards, that it would warn about unreachable code. There was a bug in my code today which I tracked down to a code transposition that would have been easily spotted with such a warning.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8494#changelog
http://ghc.haskell.org/trac/ghc/ticket/8501
http://ghc.haskell.org/trac/ghc/ticket/8501#8501: Improve error message when using rec/mdo keyword without RecursiveDo extention.Mon, 04 Nov 2013 07:26:41 GMTshelarcy<p>
GHC shows unhelpful error message when using rec keyword and/or mdo keyword without RecursiveDo extention.
</p>
<pre class="wiki">module NoRecursiveDo where
foo = do
rec str <- return "foo"
putStrLn str
</pre><pre class="wiki">$ ghc -c NoRecursiveDo.hs
NoRecursiveDo1.hs:4:5:
Parse error in pattern: rec
Possibly caused by a missing 'do'?
</pre><pre class="wiki">module NoRecursiveDo2 where
bar = mdo
str <- return "bar"
putStrLn str
</pre><pre class="wiki">$ ghc -c NoRecursiveDo2.hs
NoRecursiveDo2.hs:4:9: parse error on input `<-'
</pre><pre class="wiki">module NoRecursiveDo3 where
baz = mdo
putStrLn "baz"
</pre><pre class="wiki">$ ghc -c NoRecursiveDo3.hs
NoRecursiveDo3.hs:3:7:
Not in scope: `mdo'
Perhaps you meant `mod' (imported from Prelude)
</pre><p>
I think that GHC should suggest to use RecursiveDo extention when using mdo/rec keyword.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8501#changelog
http://ghc.haskell.org/trac/ghc/ticket/8504
http://ghc.haskell.org/trac/ghc/ticket/8504#8504: Provide minor GC residency estimatesTue, 05 Nov 2013 07:50:59 GMTezyang<p>
Currently, the residency statistics (e.g. max residency and current residency) are only updated when a major garbage collection occurs. While this is the only way to ensure an accurate residency count, there are times when a residency estimate would be desirable, since only taking the sample on major GC can be somewhat low resolution. We already collect and report this information on verbose GC stats, so all that needs to be done is to expose it via GHC.Stats. Should be an easy patch, good for someone who wants to play around in the RTS.
</p>
<p>
Here is a simple patch that switches residency to the inaccurate version:
</p>
<pre class="wiki">diff --git a/rts/Stats.c b/rts/Stats.c
index c19f23c..c71d0fb 100644
--- a/rts/Stats.c
+++ b/rts/Stats.c
@@ -449,7 +449,6 @@ stat_endGC (Capability *cap, gc_thread *gct,
CAPSET_HEAP_DEFAULT,
mblocks_allocated * MBLOCK_SIZE_W * sizeof(W_));
- if (gen == RtsFlags.GcFlags.generations-1) { /* major GC? */
if (live > max_residency) {
max_residency = live;
}
@@ -459,7 +458,6 @@ stat_endGC (Capability *cap, gc_thread *gct,
traceEventHeapLive(cap,
CAPSET_HEAP_DEFAULT,
live * sizeof(W_));
- }
if (slop > max_slop) max_slop = slop;
}
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8504#changelog
http://ghc.haskell.org/trac/ghc/ticket/8510
http://ghc.haskell.org/trac/ghc/ticket/8510#8510: Clear up what extensions are needed at a Template Haskell splice siteFri, 08 Nov 2013 11:38:16 GMTsimonpj<p>
Suppose you write
</p>
<pre class="wiki">module M where
data T = ...
$(cleverThFunction ''T)
</pre><p>
where <tt>cleverThFunction</tt> is some Template Haskell code in a library somewhere. Question:
</p>
<ul><li><strong>If <tt>cleverThFunction</tt> generates code that uses <tt>GADTs</tt>, or <tt>ConstraintKinds</tt>, or <tt>TypeFamilies</tt> or whatnot, do those language extension flags have to be in force in module M, or only at the definition of <tt>cleverThFunction</tt>?</strong>
</li></ul><p>
Currently the situation is anarchic; see below. It should be made tidy. My personal preference is to say that the extensions must be in force in the definition of <tt>cleverThFunction</tt>, but <strong>not</strong> at the splice site. Reason: the client doesn't know or care how <tt>cleverThFunction</tt> works. This decision would be compatible with the handling of overlapping instances.
</p>
<p>
Gergely writes:
</p>
<p>
There are a lot of extensions that simply can't be used with TH:
</p>
<pre class="wiki"> - n+k,
- RecursiveDo,
- TransformListComp,
- Arrows,
- ImplicitParams,
- TupleSections,
- Monadcomprehensions.
</pre><p>
The rest can be grouped into two parts.
</p>
<p>
The following extensions still work when spliced in without the corresponding language pragma:
</p>
<pre class="wiki"> - UnicodeSyntax,
- LambdaCase,
- NamedFieldPuns,
- RecordWildCards,
- DataTypeContexts (and you get rid of the deprecation warning
generation this way :)),
- ConstraintKind,
- MagicHash (note that UnboxedTuples is in the other part),
- TraditionalRecordSyntax,
- MultiWayIf,
- GADTs (extra nice example at the end of this message).
</pre><p>
The following needs the pragma at the place of splicing:
</p>
<pre class="wiki"> - PostfixOperators,
- ScopedTypeVariables,
- Rank2, RankN,
- deriving typeable and data,
- UnboxedTuples,
- ViewPatterns,
- ParallelListComp,
- ExistentialQuantification,
- EmptyDataDecls,
- TypeFamilies,
- MultiParamTypeClasses,
- FunctionalDependencies.
</pre><p>
I don't see any trivial distinction, like based on Reader vs Typechecker, or anything like that. In particular
</p>
<ul><li>Note <tt>ViewPatterns</tt> vs <tt>LambdaCase</tt>.
</li><li>Note <tt>GADTs</tt> vs <tt>Rank2</tt>.
</li></ul><p>
A very interesting example is <tt>ExplicitForAll</tt>. The AST for polymorphic functions always have explicit foralls in TH.Syntax; so there is no way to require the user at the point of splicing to enable the language extension.
</p>
<p>
GADTs are cool too:
</p>
<pre class="wiki">{-# LANGUAGE TemplateHaskell #-}
-- No need for GADTs at all!
-- {-# LANGUAGE GADTs #-}
$([d|
data Foo where
Foo1 :: Int -> Foo
Foo2 :: String -> Foo
f1 :: Foo
f1 = Foo1 5
f :: Foo -> Either Int String
f (Foo1 n) = Left n
f (Foo2 s) = Right s
|])
main = print (f f1)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8510#changelog
http://ghc.haskell.org/trac/ghc/ticket/8516
http://ghc.haskell.org/trac/ghc/ticket/8516#8516: Add (->) representation and the Invariant class to GHC.GenericsSat, 09 Nov 2013 20:39:41 GMTnfrisby<p>
We currently disallow any use of the parameter in the domain of (->).
</p>
<pre class="wiki">newtype F a = F ((a -> Int) -> Int) deriving Generic1
<interactive>:4:38:
Can't make a derived instance of `Generic1 (F g)':
Constructor `F' must use the last type parameter only as the last argument of a data type, newtype, or (->)
In the data declaration for `F'
</pre><p>
DeriveFunctor succeeds for this F.
</p>
<p>
I'd like to add this representation type to GHC.Generics and DeriveGeneric.
</p>
<pre class="wiki">newtype (f :->: g) a = FArrow1 (f a -> g a)
</pre><p>
We could then represent the first example above. We could also derive the more interesting Generic1 (F g).
</p>
<pre class="wiki">newtype F g a = F (g a -> Int) deriving Generic1
type instance Rep1 (F g) = Rec1 g :->: Rec0 Int
instance Generic1 (F g) where
to x = F $ unRec0 . unArrow1 x . Rec1
from (F x) = FArrow1 $ Rec0 . x . unRec1
</pre><p>
Admittedly, there's not many generic definitions impeded by not having (:->:). Contra- and in-variant types are uncommon.
</p>
<p>
I'm suggesting this feature without strong motivating examples because I think this would streamline the implementation of -XDeriveGenerics in some ways while also making it more general — assuming that we added the Invariant class to base or ghc-prim.
</p>
<pre class="wiki">class Invariant t where
invmap :: (a -> b) -> (b -> a) -> t a -> t b
invmap_covariant :: Functor t => (a -> b) -> (b -> a) -> t a -> t b
invmap_covariant f _ = fmap f
instance (Invariant f,Invariant g) => Invariant (FArrow f g) where
invmap co contra (FArrow h) = FArrow $ invmap co contra . h . invmap contra co
</pre><p>
(Of course, Invariant should be a super class of Functor. :/ )
</p>
<p>
Now we can handle quite involved examples:
</p>
<pre class="wiki">newtype F g h a = F (g (h a)) deriving Generic1
instance Invariant g => Generic1 (F g h) where
to x = invmap unRec1 Rec1 $ unComp1 x
from (F x) = Comp1 $ invmap Rec1 unRec1
</pre><p>
All of that said, I'm mostly opening this ticket so I can get feedback on difficulties I might not be anticipating and have a place to reference from the compiler source code comments.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8516#changelog
http://ghc.haskell.org/trac/ghc/ticket/8523
http://ghc.haskell.org/trac/ghc/ticket/8523#8523: blowup in space/time for type checking and object size for high arity tuplesTue, 12 Nov 2013 00:47:53 GMTcarter<p>
Eric Mertens found a compilation performance issue in how GHC handles type class instance methods with many equality constraints and large arity tuples.
</p>
<p>
basically using equality constraints to force 62 variables equal, instead of using the same variable for all the tuple slots, make the type checking time go from 0.9 seconds and very little memory to ~20 seconds and ~ 700mb of ram, along with going from ~ 7,000 coercions to 700,000-400,000 coercions, and object file size of 143kb to an object file size of 2.8mb-3.1mb
</p>
<p>
I'm attaching 2 variants Tuple.hs and NeighborTuple.hs that exhibit the blowup behavior, and
MonoTuple.hs (better named PolyTuple.hs but thats a side detail) that doesn't exhibit the blow up behavior.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8523#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/8527
http://ghc.haskell.org/trac/ghc/ticket/8527#8527: The ordering of -I directives should be consistent with the ordering of -package directivesWed, 13 Nov 2013 02:44:14 GMTparcs<p>
Here's a reduced test case:
</p>
<h2 id="cpp.hs">cpp.hs</h2>
<div class="code"><pre><span class="cm">{-# LANGUAGE CPP #-}</span>
<span class="o">#</span>include <span class="s">"Typeable.h"</span>
<span class="nf">main</span> <span class="ow">=</span> return <span class="nb">()</span>
</pre></div><h2 id="commandline">command line</h2>
<pre class="wiki">$ ghc-stage2 -c -package base cpp.hs
In file included from cpp.hs:4:0:
/home/patrick/code/ghc/libraries/base/include/Typeable.h:17:2:
warning: #warning <Typeable.h> is obsolete and will be removed in GHC 7.10 [-Wcpp]
#warning <Typeable.h> is obsolete and will be removed in GHC 7.10
^
compilation IS NOT required
$ ghc-stage2 -c -package base -package containers cpp.hs
compilation IS NOT required
$ ghc-stage2 -c -package containers -package base cpp.hs
</pre><p>
Notice that if I pass <tt>-package containers</tt> to ghc, the cpp warning from Typeable.h (from the base library) doesn't appear. This is because containers also has a Typeable.h in its include path, and in the invocation of the preprocessor, containers' include path precedes base's no matter how I order the <tt>-package</tt> directives.
</p>
<p>
This behavior is unintuitive and limiting. To fix this, I think that the ordering of -I directives passed to the preprocessor should be consistent with the ordering of -package directives passed to ghc. For example, in the above test case, a warning should be shown in the 1st and 2nd invocations of ghc but not the 3rd, because in the 3rd invocation containers precedes base.
</p>
<p>
Does this sound okay?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8527#changelog
http://ghc.haskell.org/trac/ghc/ticket/8532
http://ghc.haskell.org/trac/ghc/ticket/8532#8532: Hyperbolic arc cosine fails on (-1) :: Complex r.Thu, 14 Nov 2013 12:00:11 GMTleftaroundabout<p>
When allowing for complex results, the hyperbolic arc cosine is continuously defined on all ℝ.
</p>
<p>
In the <tt>(x < (-1))</tt> real ray of the complex plane, <tt>acosh</tt> equals <tt>\z -> i * pi + acosh(abs z)</tt>, which works fine for almost all arguments. Thus, <tt>acosh (-1)</tt> should equal <tt>i * pi</tt>; however due to the implementation as
</p>
<pre class="wiki">acosh z = log (z + (z+1) * sqrt ((z-1)/(z+1)))
</pre><p>
where the denominator in the root becomes zero at <tt>z = -1</tt>, this comes out as <tt>NaN :+ NaN</tt>.
</p>
<p>
Could be fixed trivially by adding a special case
</p>
<pre class="wiki">acosh ((-1):+0) = 0:+pi
</pre><p>
to the <tt>instance (RealFloat a) => Floating (Complex a)</tt> in <tt>Data.Complex</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8532#changelog
http://ghc.haskell.org/trac/ghc/ticket/8538
http://ghc.haskell.org/trac/ghc/ticket/8538#8538: confusing specialization CORE warning, also can't mark type class instances INLINEABLE unless class defn is marked INLINEABLESun, 17 Nov 2013 23:42:31 GMTcarter<p>
As part of writing an array library for numerical purposes, I have a static sized strict list type for representing the Indexing tuple. One implementation strategy makes it a tad generic, and then I'm writing a bunch of manipulation utilities using Functor, Applicative and Foldable.
</p>
<p>
I wrote it with all the functions marked INLINABLE so i could ensure that I could have the index arith calculations SPECIALIZE in the common cases.
</p>
<p>
Unfortunately, it seems like type class instances can only marked INLINABLE if the type class definition is itself marked INLINE or INLINABLE. Considering i'm writing a numerical array library, I want to make sure that address arithmetic.
</p>
<p>
This could could be argued to be by design (and thus a wont fix).
</p>
<p>
That aside, I also get the following Warning for my "map2" function, which i found surprising. (and it perhaps is worth some investigation / cleanup )
</p>
<pre class="wiki">
src/Numerical/Types/Shape.hs:165:1: Warning:
RULE left-hand side too complicated to desugar
let {
$dFunctor :: Functor (Shape ('S N0))
[LclId]
$dFunctor =
Numerical.Types.Shape.$fFunctorShape @ 'Z $dFunctor } in
map2
@ a
@ b
@ c
@ N2
(Numerical.Types.Shape.$fApplicativeShape
@ ('S N0)
(Numerical.Types.Shape.$fFunctorShape @ ('S N0) $dFunctor)
(Numerical.Types.Shape.$fApplicativeShape
@ 'Z $dFunctor Numerical.Types.Shape.$fApplicativeShape0))
</pre><pre class="wiki">{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE BangPatterns #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE DeriveDataTypeable #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE UndecidableInstances #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE StandaloneDeriving #-}
{-# LANGUAGE CPP #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE NoImplicitPrelude #-}
module Numerical.Types.Shape where
import GHC.Magic
import Data.Monoid
import Data.Functor
import Data.Foldable
import Control.Applicative
-- import Numerical.Types.Nat
import Prelude (seq, ($!),($),Show(..),Eq(),Int)
data Nat = S !Nat | Z
type N0 = Z
type N1= S N0
type N2 = S N1
type N3 = S N2
type N4 = S N3
{-
not doing the HLIST style shape because I don't want to have
any pattern matchings going on.
Also would play hell with locality quality in the address translation hackery,
because there'd be an extra load to get those ints!
-}
infixr 3 :*
{-
the concern basically boils down to "will it specialize / inline well"
-}
data Shape (rank :: Nat) a where
Nil :: Shape Z a
(:*) :: !(a) -> !(Shape r a ) -> Shape (S r) a
--deriving instance (Show (Shape rank a))
-- deriving instance Eq (Shape rank a)
-- #if defined( __GLASGOW_HASKELL__ ) && ( __GLASGOW_HASKELL__ >= 707)
--deriving instance Typeable (Shape rank a)
-- #endif
instance Functor (Shape Z) where
fmap = \ f Nil -> Nil
{-# INLINABLE fmap #-}
{-# SPECIALIZE fmap :: (a ->b )-> (Shape Z a)-> (Shape Z b) #-}
instance (Functor (Shape r)) => Functor (Shape (S r)) where
fmap = \ f (a :* rest) -> f a :* fmap f rest
{-# INLINABLE fmap #-}
{-# SPECIALIZE fmap :: (a ->b )-> (Shape N1 a)-> (Shape N1 b) #-}
{-# SPECIALIZE fmap :: (a ->b )-> (Shape N2 a)-> (Shape N2 b) #-}
instance Applicative (Shape Z) where
pure = \ _ -> Nil
{-# INLINE pure #-}
(<*>) = \ _ _ -> Nil
{-# INLINE (<*>) #-}
{-# SPECIALIZE pure :: a -> Shape Z a #-}
{-# SPECIALIZE (<*>) :: Shape Z (a -> b) -> Shape Z a -> Shape Z b #-}
instance Applicative (Shape r)=> Applicative (Shape (S r)) where
pure = \ a -> a :* (pure a)
{-# INLINE pure #-}
(<*>) = \ (f:* fs) (a :* as) -> f a :* (inline (<*>)) fs as
{-# INLINE (<*>) #-}
{-# SPECIALIZE pure :: a -> (Shape Z a) #-}
{-# SPECIALIZE pure :: a -> (Shape N1 a) #-}
{-# SPECIALIZE pure :: a -> (Shape N2 a )#-}
instance Foldable (Shape Z) where
foldMap = \ _ _ -> mempty
{-# INLINE foldMap #-}
foldl = \ _ init _ -> init
{-# INLINE foldl #-}
foldr = \ _ init _ -> init
{-# INLINE foldr #-}
foldr' = \_ !init _ -> init
{-# INLINE foldr' #-}
foldl' = \_ !init _ -> init
{-# INLINE foldl' #-}
-- {-# SPECIALIZE foldMap :: Monoid m => (a -> m)-> Shape Z a -> m #-}
-- {-# SPECIALIZE foldl :: (a ->b -> a) -> a -> Shape Z b -> a #-}
-- {-# SPECIALIZE foldr :: (b ->a -> a) -> a -> Shape Z b -> a #-}
-- {-# SPECIALIZE foldl' :: (a ->b -> a) -> a -> Shape Z b -> a #-}
-- {-# SPECIALIZE foldr' :: (b ->a -> a) -> a -> Shape Z b -> a #-}
instance (Foldable (Shape r)) => Foldable (Shape (S r)) where
foldMap = \f (a:* as) -> f a <> foldMap f as
{-# INLINE foldMap #-}
foldl' = \f !init (a :* as) -> let next = f init a in next `seq` (inline foldl) f next as
{-# INLINE foldl' #-}
foldr' = \f !init (a :* as ) -> f a $! (inline foldr) f init as
{-# INLINABLE foldr' #-}
foldl = \f init (a :* as) -> let next = f init a in (inline foldl) f next as
{-# INLINE foldl #-}
foldr = \f init (a :* as ) -> f a $ (inline foldr) f init as
{-# INLINE foldr #-}
{-# SPECIALIZE foldMap::Monoid m => (a -> m)-> Shape N1 a -> m #-}
{-# SPECIALIZE foldl :: (a ->b -> a) ->a -> Shape N1 b -> a #-}
{-# SPECIALIZE foldr :: (b ->a -> a) -> a -> Shape N1 b -> a #-}
{-# SPECIALIZE foldl' :: (a ->b -> a) -> a -> Shape N1 b -> a #-}
{-# SPECIALIZE foldr' :: (b ->a -> a) -> a -> Shape N1 b -> a #-}
{-# SPECIALIZE foldMap :: Monoid m => (a -> m)-> Shape N2 a -> m #-}
{-# SPECIALIZE foldl :: (a ->b-> a) ->a -> Shape N2 b -> a #-}
{-# SPECIALIZE foldr :: (b ->a -> a) -> a -> Shape N2 b -> a #-}
{-# SPECIALIZE foldl' :: (a ->b -> a) -> a -> Shape N2 b -> a #-}
{-# SPECIALIZE foldr' :: (b ->a -> a) -> a -> Shape N2 b -> a #-}
--
map2 :: (Applicative (Shape r))=> (a->b ->c) -> (Shape r a) -> (Shape r b) -> (Shape r c )
map2 = \f l r -> pure f <*> l <*> r
{-# INLINABLE map2 #-}
{-# SPECIALIZE map2 :: (a -> b -> c ) -> (Shape Z a) -> (Shape Z b) -> (Shape Z c )#-}
{-# SPECIALIZE map2 :: (a -> b -> c ) -> (Shape N1 a) -> (Shape N1 b) -> (Shape N1 c )#-}
{-# SPECIALIZE map2 :: (a -> b -> c ) -> (Shape N2 a) -> (Shape N2 b) -> (Shape N2 c )#-}
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8538#changelog
http://ghc.haskell.org/trac/ghc/ticket/8552
http://ghc.haskell.org/trac/ghc/ticket/8552#8552: Rename StgArrWords to StgArrBytesThu, 21 Nov 2013 13:15:14 GMTTarrasch<p>
Since <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3800" title="bug: sizeofByteArray# returns allocated words, not requested length in bytes (closed: fixed)">#3800</a>, <tt>StgArrWords</tt> contains a certain number of words and not bytes. One can easily forget this and make programming mistakes. For example if you try to store the number of words in the <tt>bytes</tt> field, the garbage collector won't honor your decision. (I learned the hard way :))
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8552#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/8556
http://ghc.haskell.org/trac/ghc/ticket/8556#8556: Invalid constructor names are accepted in data declarationsFri, 22 Nov 2013 21:08:37 GMTdolio<p>
Earlier today, someone was asking on #haskell why the constructor name <tt>(^)</tt> wouldn't work in GADT definitions. My response was that <tt>(^)</tt> isn't a constructor name, but much to my surprise, GHC accepts such names in a regular data declaration:
</p>
<pre class="wiki">data Foo = F | (^^^^) Int Int
</pre><p>
This creates a <tt>Foo</tt> type and value constructor <tt>F</tt>, but no value constructor <tt>(^^^^)</tt>. However, in 7.6.3, if DataKinds are enabled, both constructors appear at the type level.
</p>
<p>
In HEAD, the same definition is accepted, with only <tt>F</tt> existing at the value level, as before. But at the type level, both <tt>F</tt> and <tt>(^^^^)</tt> just generate errors that <tt>Foo</tt> is not a promotable type. At that point, I think there's no question that the declaration should just be ruled out.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8556#changelog