GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?status=!closed&reporter=claus&order=priority
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/query?status=!closed&reporter=claus&order=priority
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/1216
http://ghc.haskell.org/trac/ghc/ticket/1216#1216: Missed opportunity for let-no-esapeMon, 12 Mar 2007 16:57:04 GMTclaus<p>
readArray/writeArray call GHC.Arr.index, which seems inexplicably slow
for 2d arrays. inexplicably, because simply copying the default implementation
of index from GHC.Arr into the local module can speed things up considerably.
</p>
<p>
originally raised in this thread:
<a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2007-March/023394.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-cafe/2007-March/023394.html</a>
</p>
<p>
shortened example or matrix/vector-multiplication attached. comment out
the first line of myindex to use the local copy. this results in a speedup
from 20s to 13s (time ./Index 100000) on my system, not to mention the
difference in space usage (a factor of 1000 in allocation, according to
+RTS -sstderr..).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1216#changelog
http://ghc.haskell.org/trac/ghc/ticket/2344
http://ghc.haskell.org/trac/ghc/ticket/2344#2344: oddity with package prefixes for data constructorsWed, 04 Jun 2008 22:56:15 GMTclaus<p>
consider
</p>
<pre class="wiki">$ ./ghc-6.9.20080514/bin/ghcii.sh
GHCi, version 6.9.20080514: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude> :browse Data.Time.Clock
getCurrentTime :: IO UTCTime
newtype DiffTime
= time-1.1.2.0:Data.Time.Clock.Scale.MkDiffTime Data.Fixed.Pico
newtype NominalDiffTime
= time-1.1.2.0:Data.Time.Clock.UTC.MkNominalDiffTime Data.Fixed.Pico
data UTCTime
= UTCTime {utctDay :: time-1.1.2.0:Data.Time.Calendar.Days.Day,
utctDayTime :: DiffTime}
newtype UniversalTime
= ModJulianDate {getModJulianDate :: Rational}
addUTCTime :: NominalDiffTime -> UTCTime -> UTCTime
diffUTCTime :: UTCTime -> UTCTime -> NominalDiffTime
picosecondsToDiffTime :: Integer -> DiffTime
secondsToDiffTime :: Integer -> DiffTime
</pre><p>
there is only one time package installed, so i'm surprised to see any package prefixes at all here
</p>
<pre class="wiki">$ ./ghc-6.9.20080514/bin/ghc-pkg.exe find-module Data.Time.\*
c:/fptools/ghc/ghc-6.9.20080514\package.conf:
time-1.1.2.0
</pre><p>
but by what system do some things get prefixes and others don't? are there any invisible modules that need the distinction, or is this an output bug?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2344#changelog
http://ghc.haskell.org/trac/ghc/ticket/2630
http://ghc.haskell.org/trac/ghc/ticket/2630#2630: installed packages should have a src-dirs field, for access to optionally installed sourcesSun, 28 Sep 2008 13:08:52 GMTclaus<p>
In a typical ghc+packages installation, there are no Haskell sources. That makes life difficult for source-code-based tools, such as Haddock or HaRe (as far as I can see from <tt>--show-iface</tt> output, not even the import hierarchy is visible anymore?).
</p>
<p>
(1) It would be useful if Ghc Api clients and Ghc users could easily find the matching source for installed packages, via a <tt>src-dirs</tt> field in the installed package description (if field is empty, no source has been installed).
</p>
<p>
(2) It would be useful if matching sources could easily be added for installed packages. This would require editing the package description. Should there be an <tt>edit</tt> command for <tt>ghc-pkg</tt>?
</p>
<p>
(3) An alternative to a <tt>src-dirs</tt> field would be to install sources in a separate source-package database, as long as it is easy to find the source from the binary package.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2630#changelog
http://ghc.haskell.org/trac/ghc/ticket/3055
http://ghc.haskell.org/trac/ghc/ticket/3055#3055: Int / Word / IntN / WordN are unequally optimizedSun, 01 Mar 2009 13:48:00 GMTclaus<p>
A lot of thought has been put into optimizing usage of <tt>Int</tt>, but not all of these tweaks have been copied for usage of <tt>Word</tt>, and the specific-size versions of both have even fewer optimizations. The consequence is that switching from signed to unsigned, or from unspecified to specified size, can result in dramatic performance loss.
</p>
<ul><li>builtin rules (<tt>prelude/PrelRules</tt>) cover <tt>Int</tt> and <tt>Word</tt>, but not sized alternatives
</li></ul><ul><li><tt>SPECIALI[SZ]E</tt> pragmas cover <tt>Int</tt>, but little of the others. Try
<pre class="wiki">find libraries/ -name _darcs -prune -o -name *hs |
xargs grep SPECIAL | grep '\<Int\|\<Word'
</pre></li></ul><ul><li>some instances have special cases for <tt>Int</tt>, but not for the others (for instance, the <tt>Enum</tt> instance for <tt>Int</tt> uses specialised <tt>enumFromTo</tt> code, the <tt>Word</tt> version uses generic code; <tt>base/GHC/Enum.hs</tt> and <tt>base/GHC/Word.hs</tt>)
</li></ul><ul><li>some <tt>RULES</tt> help optimizing the special cases for <tt>Int</tt> further (again, see the <tt>Enum</tt> instance for <tt>Int</tt> for an example)
</li></ul><p>
See this thread <a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-users/2009-February/016705.html"><span class="icon"></span>Int vs Word performance?</a> for more discussion.
</p>
<p>
related tickets: <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/2270" title="bug: gcd is specialised only for Int (closed: duplicate)">#2270</a>, <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3051" title="bug: Add product/sum/maximum/minimum specialisations for more atomic types (closed: duplicate)">#3051</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3055#changelog
http://ghc.haskell.org/trac/ghc/ticket/2356
http://ghc.haskell.org/trac/ghc/ticket/2356#2356: GHC accepts multiple instances for the same type in different modulesTue, 10 Jun 2008 12:25:27 GMTclaus<p>
as mentioned by Simon PJ in this thread:
</p>
<p>
<a class="ext-link" href="http://www.haskell.org/pipermail/haskell/2008-June/020436.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell/2008-June/020436.html</a>
</p>
<p>
here is the example, spelled out:
</p>
<pre class="wiki">module B0 where
class C a where c :: a -> String
data T = T deriving Show
module B1 where
import B0
instance C T where c _ = "B1"
b = c T
module B2 where
import B0
instance C T where c _ = "B2"
b = c T
module Main where
import B1
import B2
main = print (B1.b,B2.b)
</pre><p>
this is accepted without flags or errors and prints <tt>("B1","B2")</tt>.
</p>
<p>
the <a class="ext-link" href="http://haskell.org/onlinereport/decls.html#sect4.3.2"><span class="icon"></span>language report, section 4.3.2</a> clearly states:
</p>
<blockquote>
<p>
A type may not be declared as an instance of a particular class more than once in the program.
</p>
</blockquote>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2356#changelog
http://ghc.haskell.org/trac/ghc/ticket/2258
http://ghc.haskell.org/trac/ghc/ticket/2258#2258: ghc --cleanupThu, 01 May 2008 22:51:29 GMTclaus<p>
calling <tt>ghc --make</tt> generates a lot of files, <tt>.o</tt>, <tt>.hi</tt>, <tt>.exe</tt>, <tt>.exe.manifest</tt>, .. moreover, those files may be in different directories, etc.
</p>
<p>
a nice way to get rid of all those leftovers would be a <tt>ghc --cleanup</tt>, with the same options and parameters as <tt>ghc --make</tt>, which would delete everything that <tt>ghc --make</tt> would generate.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2258#changelog
http://ghc.haskell.org/trac/ghc/ticket/2345
http://ghc.haskell.org/trac/ghc/ticket/2345#2345: :browse limitations (browsing virtual namespaces, listing namespaces)Wed, 04 Jun 2008 23:16:25 GMTclaus<ol><li>:browse cannot be used with virtual namespaces:
<pre class="wiki">import Prelude ()
import qualified Data.List as Folds(foldr)
import qualified Data.Maybe as Folds(maybe)
</pre></li></ol><pre class="wiki">*Main> :browse *Main
Folds.foldr :: (a -> b -> b) -> b -> [a] -> b
Folds.maybe :: b -> (a -> b) -> Data.Maybe.Maybe a -> b
*Main> :browse *Folds
Could not find module `Folds':
Use -v to see a list of the files searched for.
</pre><p>
it would be useful if GHCi's :browse supported this Haskell module system feature, allowing "virtual" namespaces to be browsed just like "real" ones.
</p>
<ol start="2"><li>to use :browse, one needs to know the precise module name
</li></ol><p>
when using some packages, like OpenGL, i never can remember where in the hierarchy their modules are placed, so i can't even get started :browsing them.
</p>
<p>
(a) it would be useful if <tt>ghc-pkg</tt> functionality was part of the <tt>GHC API</tt>, and accessible from within GHCi, or if GHCi knew which instance of <tt>ghc-pkg</tt> it is associated with (<tt>:!ghc-pkg field OpenGL exposed-modules</tt> does not work unless the ghc-pkg in the PATH happens to match the GHCi in use..).
</p>
<p>
(b) it would be nicer if GHCi's <tt>:browse</tt> itself had an option to list available namespaces matching a pattern, so that one could narrow down to what one wants to <tt>:browse</tt>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2345#changelog
http://ghc.haskell.org/trac/ghc/ticket/3123
http://ghc.haskell.org/trac/ghc/ticket/3123#3123: make INLINE work for recursive definitions (generalized loop peeling/loop unrolling)Wed, 25 Mar 2009 16:48:55 GMTclaus<p>
Inlining refers to the unfolding of definitions, ie replacing uses of identifiers with the definitions bound to them. Doing this at compile time can expose potential for other optimizations. As described in the User Guide, this is currently limited to non-recursive definitions, to avoid non-terminating recursion in the inliner.
Unfolding Recursions
</p>
<p>
Since many definitions in non-trivial programs are either recursive themselves or are built from recursion combinators, leaving recursion out of inlining alltogether is a serious limitation, especially in view of the encoding of loops via tail recursion. In conventional languages, loop transformations such as loop unrolling are at the heart of optimizing high performance code (for a useful overview, see Compiler Transformations for High-Performance Computing, ACM Computing Surveys, 1994). As a consequence, many performance-critical Haskell programs contain hand-unrolled and hand-peeled recursions, which is error-prone and obscures declarative contents.
</p>
<p>
More details, examples, and an informal spec: <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/Inlining">wiki:Inlining</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3123#changelog