GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?status=!closed&order=id
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/query?status=!closed&order=id
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/149
http://ghc.haskell.org/trac/ghc/ticket/149#149: missed CSE opportunityThu, 12 Jun 2003 09:29:46 GMTnobody<p>
Don't know if this is a bug, but it was at least
_surprising_ to find that
</p>
<pre class="wiki">playerMostOccur [a] = a
playerMostOccur (x:xs)
| numOccur x (x:xs) > numOccur (playerMostOccur xs) xs = x
| otherwise = playerMostOccur xs
</pre><p>
was exponentially slower when compiled with ghc-5.04.2
-O than:
</p>
<pre class="wiki">playerMostOccur [a] = a
playerMostOccur (x:xs)
| numOccur x (x:xs) > numOccur pmo xs = x
| otherwise = pmo
where pmo = playerMostOccur xs
</pre><p>
Although the student responsible for the code couldn't
spot the
obvious optimisation, I was expecting that GHC's
optimiser would. :)
If it's not a bug, could you explain it to me?
</p>
<p>
-Greg(gregm.at.cs.uwa.edu.au)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/149#changelog
http://ghc.haskell.org/trac/ghc/ticket/229
http://ghc.haskell.org/trac/ghc/ticket/229#229: Integer overflow in array allocationWed, 16 Jun 2004 08:14:56 GMTjosefs<p>
When asked to create a sufficiently large array ghci
coredumps.
</p>
<pre class="wiki">\begin{code}
import Data.Array.ST
import Control.Monad.ST
import GHC.Base
example = runST (do arr <- newArray (minInt,maxInt)
False
go arr)
where go :: STArray s Int Bool -> ST s Bool
go arr = readArray arr 3
\end{code}
</pre><p>
Load this into ghci and type 'example'.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/229#changelog
http://ghc.haskell.org/trac/ghc/ticket/284
http://ghc.haskell.org/trac/ghc/ticket/284#284: RPM doesn't support --prefixMon, 13 Dec 2004 01:54:24 GMTskaller<pre class="wiki">After installing ghc for linux using rpm with
--prefix=/usr/local,
the ghc scriipt incorrectly thinks the libraries etc
are in /usr:
#!/bin/sh
GHCBIN="/usr/lib/ghc-6.2.2/ghc-6.2.2";
TOPDIROPT="-B/usr/lib/ghc-6.2.2";
# Mini-driver for GHC
exec $GHCBIN $TOPDIROPT ${1+"$@"}
After editing, at least the compiler actually starts up :)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/284#changelog
http://ghc.haskell.org/trac/ghc/ticket/285
http://ghc.haskell.org/trac/ghc/ticket/285#285: hp-ux 11.11 binariesMon, 20 Dec 2004 22:20:03 GMTamyhr<p>
Looks like there hasn't been a binary dist for ghc in a
very long time, any chance we could see one soon?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/285#changelog
http://ghc.haskell.org/trac/ghc/ticket/307
http://ghc.haskell.org/trac/ghc/ticket/307#307: Implicit Parameters and monomorphismWed, 16 Feb 2005 17:01:08 GMTnobody<pre class="wiki">http://www.haskell.org/pipermail/haskell-cafe/2005-January/008571.html
Notes some oddness with recursive binding of implicit
parameters. Roughly, giving a type signature to a
function with implicit params causes its bindings to
act recursively, despite what section 7.4.5.2 of the
user's guide says.
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/307#changelog
http://ghc.haskell.org/trac/ghc/ticket/314
http://ghc.haskell.org/trac/ghc/ticket/314#314: #line pragmas not respected inside nested commentsMon, 28 Feb 2005 18:09:41 GMTnobody<pre class="wiki">If one tries to compile a .hs file, with the -cpp
option and the file contains
C-style comments (/* comment */), then the linenumbers
GHC reports
are wrong.
Minimal file exhibiting the error:
---
{-
/*
* Copyright (c) 2005 Jesper Louis Andersen
<jlouis@mongers.org>
*
* Permission to use, copy, modify, and distribute this
software for any
* purpose with or without fee is hereby granted,
provided that the above
* copyright notice and this permission notice appear
in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR
DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE
AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
SOFTWARE.
*/
-}
c = 3 * "string"
main = putStrLn $ show c
----
; ghc -cpp tmp.hs
tmp.hs:6:
No instance for (Num [Char])
arising from use of `*' at tmp.hs:6
In the definition of `c': c = 3 * "string"
Which is clearly wrong, since ``c'' is not defined on
line 6.
Note I am not sure wether it is in the parser, or it is
rather in compilation
chain where cpp gets invoked one has to look for the
error. I have filed
it as a parser-bug nonetheless.
Fix: cpp(1) seems to output comments in the style
# xx "filename"
where ``xx'' is a number stating the linenumber in the
original file.
Keeping track of this probably fixes the bug.
CPP version: GNU CPP from GCC 3.3.5
Operating System: OpenBSD 3.6-current (GENERIC) #1: Sun
Feb 20 10:23:54 CET 2005
Submitter: Jesper Louis Andersen <jlouis@mongers.org>
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/314#changelog
http://ghc.haskell.org/trac/ghc/ticket/322
http://ghc.haskell.org/trac/ghc/ticket/322#322: fromInteger-related pattern match overlap warningsMon, 14 Mar 2005 04:19:50 GMTashley-y<pre class="wiki">The compiler incorrectly gives "Warning: Pattern match(es) are
overlapped" for this file:
{-# OPTIONS -Werror #-}
module Buggy where
instance (Num a) => Num (Maybe a) where
(Just a) + (Just b) = Just (a + b)
_ + _ = Nothing
(Just a) - (Just b) = Just (a - b)
_ - _ = Nothing
(Just a) * (Just b) = Just (a * b)
_ * _ = Nothing
negate (Just a) = Just (negate a)
negate _ = Nothing
abs (Just a) = Just (abs a)
abs _ = Nothing
signum (Just a) = Just (signum a)
signum _ = Nothing
fromInteger = Just . fromInteger
f :: Maybe Int -> Int
f 1 = 1
f Nothing = 2
f _ = 3
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/322#changelog
http://ghc.haskell.org/trac/ghc/ticket/344
http://ghc.haskell.org/trac/ghc/ticket/344#344: arrow notation: incorrect scope of existential dictionariesThu, 07 Apr 2005 20:39:35 GMTnobody<pre class="wiki">ghc-6.4: panic! (the `impossible' happened, GHC version
6.4):
cgPanic
deref{v a1yz}
static binds for:
local binds for:
SRT labelghc-6.4: panic! (the `impossible'
happened, GHC version 6.4):
initC: srt
Please report it as a compiler bug to
glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
I've attached a test driver that can reproduce the problem.
-- Esa Pulkkinen <esa.pulkkinen@kotiposti.net>
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/344#changelog
http://ghc.haskell.org/trac/ghc/ticket/345
http://ghc.haskell.org/trac/ghc/ticket/345#345: GADT - fundep interactionFri, 08 Apr 2005 10:02:38 GMTbring<pre class="wiki">GADTs and fundeps don't seem to interact in the way
that I (perhaps naively) expect. I expected that for
each case, the type variables would be instantiated
according to the type of the constructors, and then the
fundep would be used to figure out the result type.
{-# OPTIONS_GHC -fglasgow-exts #-}
data Succ n
data Zero
class Plus x y z | x y -> z
instance Plus Zero x x
instance Plus x y z => Plus (Succ x) y (Succ z)
infixr 5 :::
data List :: * -> * -> * where
Nil :: List a Zero
(:::) :: a -> List a n -> List a (Succ n)
append :: Plus x y z => List a x -> List a y -> List a z
append Nil ys = ys
append (x ::: xs) ys = x ::: append xs ys
{-
GHC 6.4 says:
Couldn't match the rigid variable `y' against `Succ z'
`y' is bound by the type signature for `append'
Expected type: List a y
Inferred type: List a (Succ z)
In the expression: x ::: (append xs ys)
In the definition of `append': append (x ::: xs) ys
= x ::: (append xs ys)
-}
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/345#changelog
http://ghc.haskell.org/trac/ghc/ticket/367
http://ghc.haskell.org/trac/ghc/ticket/367#367: Infinite loops can hang Concurrent HaskellTue, 26 Apr 2005 07:35:26 GMTsimonpj<pre class="wiki">An infinite loop that does not allocate can hang
Concurrent Haskell, becuase no thread switching
occurs. Demo code below (from Koen Claessen).
Bites occasionally, but not often.
Simon
module Main where
import Control.Concurrent
( forkIO
, threadDelay
, killThread
, newEmptyMVar
, takeMVar
, putMVar
)
import Data.IORef
import IO( hFlush, stdout )
timeout :: Int -> a -> IO (Maybe a)
timeout n x =
do put "Race starts ..."
resV <- newEmptyMVar
pidV <- newEmptyMVar
let waitAndFail =
do put "Waiting ..."
threadDelay n
put "Done waiting!"
putMVar resV Nothing
eval =
do put "Evaluating ..."
x `seq` put "Done!"
putMVar resV (Just x)
-- used "mfix" here before but got non-termination
problems
-- (not sure they had anything to do with mfix)
pid1 <- forkIO $ do pid2 <- takeMVar pidV
eval
killThread pid2
pid2 <- forkIO $ do waitAndFail
killThread pid1
putMVar pidV pid2
put "Blocking ..."
takeMVar resV
put s =
do putStrLn s
hFlush stdout
main =
do timeout 1 (sum (repeat 1))
<<<
The above program produces the following (expected
result):
>>>
Race starts ...
Blocking ...
Evaluating ...
Waiting ...
Done waiting!
<<<
If you replace 'sum (repeat 1)' by 'last (repeat 1)' the
program hangs.
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/367#changelog
http://ghc.haskell.org/trac/ghc/ticket/393
http://ghc.haskell.org/trac/ghc/ticket/393#393: functions without implementationsThu, 26 May 2005 10:53:23 GMTc_maeder<pre class="wiki">Allow to declare a function by only supplying its type
signature.
This feature shall enhance rapid prototyping by fixing
an interface but leaving some functions unimplemented.
Currently this can be (only) simulated by supplying
dummy implementations, like
f :: ...
f = undefined
Since it is possible to supply dummy data types by
"data T" (not followed by "="), allowing functions
without implementations seems almost to be a logical
consequence. Surely, the compiler should emit warnings
for missing implementations.
It would be nice if such function declarations via type
signatures could be repeated at any position within a
module.
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/393#changelog
http://ghc.haskell.org/trac/ghc/ticket/418
http://ghc.haskell.org/trac/ghc/ticket/418#418: throwTo to a thread inside 'block'Sun, 10 Jul 2005 22:41:36 GMTremit<p>
[copy-pasting my original mail
(<a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-bugs/2005-June/005235.html"><span class="icon"></span>http://www.haskell.org/pipermail/glasgow-haskell-bugs/2005-June/005235.html</a>)]
</p>
<p>
Good evening,
</p>
<p>
I just stumbled across a segfault caused when running the
following small program. (During an attempt to implement
single-assignment variables.)
</p>
<pre class="wiki">> module Main where
>
> import Control.Concurrent
> import System.IO.Unsafe (unsafeInterleaveIO)
>
> main = do
> v <- newEmptyMVar
> a <- unsafeInterleaveIO (readMVar v)
> t <- forkIO (print a)
> threadDelay (1000*1000)
> killThread t
> forkIO (print a)
> putMVar v ()
</pre><p>
The crucial part about it seems to be the interruption
of the
lazy IO. Typing Ctl-c while running the first "print a"
by hand
from ghci instead of the forkIO+killThread doesn't change
behaviour:
</p>
<pre class="wiki"> Prelude System.IO.Unsafe Control.Concurrent> v <- newEmptyMVar
Prelude System.IO.Unsafe Control.Concurrent> a <- unsafeInterleaveIO (readMVar v)
Prelude System.IO.Unsafe Control.Concurrent> print a
Interrupted.
Prelude System.IO.Unsafe Control.Concurrent> forkIO (print a)
Prelude System.IO.Unsafe Control.Concurrent> putMVar v ()
zsh: segmentation fault (core dumped) ghci
</pre><p>
Both 6.4 and 6.2.1 crash when running main from ghci.
When running it as a compiled executable everything is
fine.
</p>
<p>
Although I'm pretty sure I've seen 6.2.1 crashing
on it when run with -e main, I cannot reproduce it
anymore. 6.4
certainly happily runs it with -e main. (A serious lack
of sleep
the last week may play a role too.. :-/)
</p>
<p>
Whether the module is compiled before being loaded into
ghci has
no effect.
</p>
<p>
Core-dumps etc can of course be sent if necessary.
</p>
<p>
Good night,
Remi
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/418#changelog
http://ghc.haskell.org/trac/ghc/ticket/427
http://ghc.haskell.org/trac/ghc/ticket/427#427: Random.StdGen slownessWed, 27 Jul 2005 08:32:05 GMTremit<pre class="wiki">Two (performance) problems in one:
{-# OPTIONS -fffi #-}
module Main (main) where
import Control.Monad
import Random
foreign import ccall unsafe "random" _crandom :: IO Int
randomInt :: (Int, Int) -> IO Int
randomInt (min,max) = do
n <- _crandom
return $ min + n `rem` range
where
range = max - min + 1
main = replicateM_ (5*10^6) $ do
x <- randomRIO (0::Int,1000) :: IO Int
x `seq` return ()
return ()
First, without the "seq" at the end, hardly anything is
evaluated and we're building huge amounts of thunks.
Three ideas about this one:
- Blame the user :)
- data StdGen = StdGen !Int !Int
Use strict fields in StdGen. Doesn't actually help
(at least in this example).
- Force evaluation of the StdGen in getStdRandom.
Does help in this example, but also changes behaviour
of the library:
x <- randomRIO undefined
currently dies only when x (or the result of a later
randomRIO) is evaluated. This change causes it to die
immediately.
Second, even _with_ the "seq", replacing "randomRIO" by
"randomInt" speeds the thing up with a factor of about
30. (2 to 3.6, in a "real world" university practicum
exercise of 900 lines of code)
Even given the fact that they're not really doing the
same thing, this seems rather much :(
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/427#changelog
http://ghc.haskell.org/trac/ghc/ticket/436
http://ghc.haskell.org/trac/ghc/ticket/436#436: Declare large amounts of constant dataThu, 11 Aug 2005 08:42:42 GMTajk<pre class="wiki">Simon Marlow wrote in Bug#635718:
"It is true that GHC doesn't have a good way to declare
large amounts of constant data. This is a shortcoming,
but not a bug (please by all means submit a feature
request)."
Submitting as requested:)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/436#changelog
http://ghc.haskell.org/trac/ghc/ticket/472
http://ghc.haskell.org/trac/ghc/ticket/472#472: Supertyping of classesThu, 20 Oct 2005 18:34:34 GMTnobody<p>
see
<a class="ext-link" href="http://repetae.net/john/recent/out/supertyping.html"><span class="icon"></span>Supertyping Suggestion for Haskell</a>
</p>
<p>
example:
</p>
<pre class="wiki">class Num a <= Group a where
(+) :: a -> a -> a
negate :: a -> a
</pre><p>
apart from multiple inheritance, it could work like this:
</p>
<pre class="wiki">import Prelude hiding ((+),negate)
import qualified Prelude ((+),negate)
class Group a where
(+) :: a -> a -> a
negate :: a -> a
instance Num a => Group a where
(+) = (Prelude.+)
negate = Prelude.negate
</pre><ul><li>coeus_at_gmx_de
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/472#changelog
http://ghc.haskell.org/trac/ghc/ticket/487
http://ghc.haskell.org/trac/ghc/ticket/487#487: powerpc/linux segfaulting binariesWed, 30 Nov 2005 02:35:12 GMTdons<p>
(Just so we don't forget) On powerpc/linux both yi and
hmp3 segfault immediately when built the -fvia-C or
-fasm ways, with (in the case of hmp3):
</p>
<pre class="wiki">(gdb) where
#0 0x100529d4 in __stginit_Binary_ ()
#1 0x1046ed78 in StgRun ()
#2 0x104671e0 in hs_add_root ()
#3 0x10467128 in startupHaskell ()
#4 0x10464f18 in main ()
</pre><p>
and in <span class="underline">stginit_Main_() with yi.
</span></p>
<p>
They die before any code in Main.main is executed.
Not much other info seems available. Both these
applications are built with the ncurses binding, and
this appears to be the same problem repored to the
lists back in June 05 by J. Bobbio:
</p>
<p>
<a class="ext-link" href="http://www.mail-archive.com/glasgow-haskell-bugs@haskell.org/msg07478.html"><span class="icon"></span>http://www.mail-archive.com/glasgow-haskell-bugs@haskell.org/msg07478.html</a>
</p>
<p>
A test case is attached to that mail.
To reproduce the hmp3 crash:
</p>
<blockquote>
<p>
$ darcs get --partial
</p>
</blockquote>
<p>
<a class="ext-link" href="http://www.cse.unsw.edu.au/~dons/code/hmp3"><span class="icon"></span>http://www.cse.unsw.edu.au/~dons/code/hmp3</a>
</p>
<p>
And follow the cabalised build process. Both
applications work on apple/powerpc, interestingly enough.
</p>
<p>
-- Don
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/487#changelog
http://ghc.haskell.org/trac/ghc/ticket/552
http://ghc.haskell.org/trac/ghc/ticket/552#552: GHCi :m doesn't restore default declFri, 08 Jun 2001 11:47:59 GMTsimonpj<p>
GHCi should remember what the 'default' setting in
force for a module is, so that after :m Foo one gets
the default setting for Foo.
</p>
<p>
This means that GHC should really record the default
setting in the interface file.
</p>
<p>
So this is related to the current bug that GHCi
doesn't remember the original source-level imports for
the module. As a result :m Foo (where Foo is a
compiled module) does not produce the right top-level
environment
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/552#changelog
http://ghc.haskell.org/trac/ghc/ticket/589
http://ghc.haskell.org/trac/ghc/ticket/589#589: Various poor type error messagesWed, 07 Dec 2005 11:40:23 GMTPeter A Jonsson [pj@…<p>
Hello,
</p>
<p>
I read the summary of the survey and noticed you wanted feedback on
where error messages could be improved. I looked up some (simple)
examples of type errors and ran them through ghc. I do not make any
claims to be an HCI expert, just a mere mortal with an opinion.
</p>
<p>
<strong>Type error 1</strong>
</p>
<p>
Code:
</p>
<pre class="wiki">1 module Test2 where
2
3 fib n = if (3 > n) then 1 else (fib (n - 1) + fib (n - 2))
4 k = fib 's'
</pre><p>
Error message:
</p>
<pre class="wiki">Test2.hs:4:
No instance for (Num Char)
arising from use of `fib' at Test2.hs:4
In the definition of `k': k = fib 's'
</pre><p>
This isn't a bad error message in my humble opinion, it does pinpoint
that I'm doing something wrong in line 4, and that there isn't an
instance for Num Char doesn't come as a surprise. However I think it
could have been more helpful by telling me that I tried to pass a Char
to a function which expected an (Ord a, Num a) => a as its parameter.
</p>
<p>
<strong>Type error 2</strong>
</p>
<p>
Code:
</p>
<pre class="wiki">1 module Test4 where
2
3 k :: Int -> Int
4 k l = 2.0*l
</pre><p>
Error message:
</p>
<pre class="wiki">Test4.hs:4:
No instance for (Fractional Int)
arising from the literal `2.0' at Test4.hs:4
In the first argument of `(*)', namely `2.0'
In the definition of `k': k l = 2.0 * l
</pre><p>
One reason this kind of error could happen is an inexperienced user
declaring the wrong type for his function, or not knowing that 2.0
would be interpreted as a Fractional.
</p>
<p>
<strong>Type error 3</strong>
</p>
<p>
Code:
</p>
<pre class="wiki">1 module Test7 where
2
3 len' xs = head (xs) + (length xs)
4 o = len' "GH"
</pre><p>
Error message:
</p>
<pre class="wiki">Test7.hs:4:
Couldn't match `Int' against `Char'
Expected type: [Int]
Inferred type: [Char]
In the first argument of `len'', namely `"GH"'
In the definition of `o': o = len' "GH"
</pre><p>
I ran this through Hugs version November 2002 and got this error
message:
</p>
<pre class="wiki">ERROR "Test7.hs":4 - Type error in application
*** Expression : len' "GH"
*** Term : "GH"
*** Type : String
*** Does not match : [Int]
</pre><p>
I find the Hugs message more clear, but that might be my background.
</p>
<p>
<strong>Type error 4</strong>
</p>
<p>
Code:
</p>
<pre class="wiki">1 module Test8 where
2
3 f = head 3
</pre><p>
Error message:
</p>
<pre class="wiki">Test8.hs:3:
No instance for (Num [a])
arising from the literal `3' at Test8.hs:3
Possible cause: the monomorphism restriction applied to the following:
f :: a (bound at Test8.hs:3)
Probable fix: give these definition(s) an explicit type signature
In the first argument of `head', namely `3'
In the definition of `f': f = head 3
</pre><p>
This one I find outright scary. For "wrong = div 3 8 + 1/2" it gives
an error message that somewhat helps me guess the error, but the above
doesn't even come close to helping me.
</p>
<p>
/ Peter
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/589#changelog
http://ghc.haskell.org/trac/ghc/ticket/595
http://ghc.haskell.org/trac/ghc/ticket/595#595: Overhaul GHC's overlapping/non-exhaustive pattern checkingWed, 17 Sep 2003 00:00:00 GMTsimonmar<p>
GHC has a module in the desugarer (Check) which checks whether patterns are overlapping and/or exhaustive, to support the flags -fwarn-overlapping-patterns and -fwarn-non-exhaustive-patterns. The code is old and crufty, and has several outstanding bugs. A rewrite is needed.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/595#changelog
http://ghc.haskell.org/trac/ghc/ticket/597
http://ghc.haskell.org/trac/ghc/ticket/597#597: Various error messages have inaccurate source locationsWed, 12 May 2004 00:00:00 GMTsimonmar<p>
Some error messages lack source location information, or have inaccurate locations. Here are the ones we know about:
</p>
<ul><li>Should point to the import decl:
<pre class="wiki"> ShowFunctions.hs:1:0
Warning: Module `Text.Show.Functions' is imported, but nothing from it is used
</pre></li><li>Should point to the instance header:
<pre class="wiki"> mod41.hs:3:0:
Illegal instance declaration for `Eq (Either a a)'
(The instance type must be of form (T a b c)
</pre></li><li>Should point to 'deriving *Eq*', not the tycon:
<pre class="wiki"> tcfail046.hs:9:8:
No instance for `Eq (Pid -> Time -> Message a -> (MessList a, Continuation a
))'
When deriving the `Eq' instance for type `Continuation'
</pre></li><li>check_tau_type doesn't have location info?
<pre class="wiki"> tcfail100.hs:7:0:
Type synonym `A' should have 1 argument, but has been given 0
In the type synonym declaration for `B'
</pre></li><li>Location in LHsModule from the parser should really span the whole file, rather than a point span at (1,0).
</li></ul><ul><li>read016: should be the lhs only?
</li><li>tcfail044: should be the instance head only.
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/597#changelog
http://ghc.haskell.org/trac/ghc/ticket/599
http://ghc.haskell.org/trac/ghc/ticket/599#599: The Front PanelWed, 12 May 2004 00:00:00 GMTsimonmar<p>
GHC's runtime has a "front panel" which displays graphical representations of parts of the runtime as a program runs. For example, it shows the amount of data in each generation, how many threads there are, the memory layout, etc.
</p>
<p>
This was a quick hack, and there are many ways in which it could be extended to become a generally useful tool.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/599#changelog
http://ghc.haskell.org/trac/ghc/ticket/602
http://ghc.haskell.org/trac/ghc/ticket/602#602: Warning SuppressionThu, 01 Jul 2004 00:00:00 GMTsimonmar<p>
It should be possible to suppress particular kinds of warnings for parts of a source file.
</p>
<p>
One way to achieve this is to allow parts of a file to be delimited by pragmas specifying the warnings to be suppressed, and then filter out the warnings during compilation based on the source location attached to the warning.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/602#changelog
http://ghc.haskell.org/trac/ghc/ticket/603
http://ghc.haskell.org/trac/ghc/ticket/603#603: GC-spy connectionThu, 01 Jul 2004 00:00:00 GMTsimonmar<p>
Connect GHC's garbage collector to the <a class="ext-link" href="http://research.sun.com/projects/gcspy/"><span class="icon"></span>GC spy tool</a>, which gives a graphical display of heap characteristics at runtime.
</p>
<p>
(Similar to the Front Panel task: <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/599" title="task: The Front Panel (new)">599</a>.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/603#changelog
http://ghc.haskell.org/trac/ghc/ticket/605
http://ghc.haskell.org/trac/ghc/ticket/605#605: Optimisation: strict enumerationsWed, 06 Oct 2004 00:00:00 GMTsimonmar<p>
Strict enumeration types should be implemented by <tt>Int#</tt>, both in the strictness analyser and for constructor fields annotated with <tt>{-# UNPACK #-}</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/605#changelog
http://ghc.haskell.org/trac/ghc/ticket/609
http://ghc.haskell.org/trac/ghc/ticket/609#609: Useful optimisation for set-cost-centreWed, 02 Feb 2005 00:00:00 GMTsimonpj<p>
If you compile, for example, drvrun014 with -prof -auto-all, you'll see stuff like
</p>
<pre class="wiki"> (scc "c" (dataToTag#)) y
</pre><p>
This generates bad code, because we end up eta-expaning dataToTag, which allocates an extra function closure.
</p>
<p>
We think that in general
</p>
<pre class="wiki"> (scc "c" e) y = scc "c" (e y)
</pre><p>
to within a small constant factor. So maybe the simplifier, or <tt>CorePrep</tt>, or both, should do this transformation.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/609#changelog
http://ghc.haskell.org/trac/ghc/ticket/618
http://ghc.haskell.org/trac/ghc/ticket/618#618: Dependency caching in ghc --makeSat, 05 May 2001 00:00:00 GMTsimonmar<p>
ghc --make should cache dependencies between runs, somehow.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/618#changelog
http://ghc.haskell.org/trac/ghc/ticket/624
http://ghc.haskell.org/trac/ghc/ticket/624#624: Program location for thread error messagesSun, 03 Jun 2001 00:00:00 GMTchak<p>
In programs with a substantial number of threads, the error messages like "indefinitely blocked" are not very helpful, because there is no indication as to which thread blocked. Having the source location of the 'fork' or so, would be much more helpful.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/624#changelog
http://ghc.haskell.org/trac/ghc/ticket/634
http://ghc.haskell.org/trac/ghc/ticket/634#634: Implement a more efficient TArrayThu, 15 Dec 2005 14:06:59 GMTanonymous<p>
<tt>Control.Concurrent.STM.TArray</tt> is implemented as an immutable array of TVars. This gives good parallelism, but isn't very efficient if you don't need that parallelism.
</p>
<p>
See: <a class="ext-link" href="http://www.haskell.org//pipermail/haskell-cafe/2005-December/012909.html"><span class="icon"></span>http://www.haskell.org//pipermail/haskell-cafe/2005-December/012909.html</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/634#changelog
http://ghc.haskell.org/trac/ghc/ticket/701
http://ghc.haskell.org/trac/ghc/ticket/701#701: Better CSE optimisationMon, 20 Feb 2006 13:58:05 GMTsimonmar<p>
GHC's CSE optimisation is pretty weedy. It looks for expressions like this:
</p>
<pre class="wiki"> let x = e1 in e2
</pre><p>
and replaces all occurrences of e1 in e2 with x. This doesn't do full CSE, but it does catch some cases. There have been case where full CSE would be significantly beneficial, though.
</p>
<p>
One possible way forward is to have a separate CSE pass that transformed expressions containing common subexpressions into the let-form above, and let the existing CSE pass do the final replacement.
</p>
<p>
We must be cautious, though: increasing sharing can introduce space leaks. Sometimes we can prove that this cannot happen, for example when the shared object is primitive, or has a bounded size.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/701#changelog
http://ghc.haskell.org/trac/ghc/ticket/728
http://ghc.haskell.org/trac/ghc/ticket/728#728: switch to compacting collection when swapping occursThu, 16 Mar 2006 10:11:55 GMTsimonmar<p>
One avenue for tuning the GC to work better in low memory conditions is for it to auto-switch to compacting collection when swapping is happening. We can detect swapping using <tt>getrusage()</tt> on Unix systems. See:
</p>
<p>
<a class="ext-link" href="http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009863.html"><span class="icon"></span>http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009863.html</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/728#changelog
http://ghc.haskell.org/trac/ghc/ticket/750
http://ghc.haskell.org/trac/ghc/ticket/750#750: Set -M, -H, -c and other memory-related values based on available virtual/physical memoryWed, 19 Apr 2006 08:25:15 GMTsimonmar<p>
From John Meacham:
</p>
<blockquote>
<p>
perhaps if <tt>-M</tt> is not otherwise set, <tt>getrlimit(RLIMIT_AS,..)</tt> could be
called and the maximum heap size set to just under that, since it is the
point that the OS will forcefully kill the program anyway.
</p>
</blockquote>
<p>
Ravi Nanavati would like to be able to set the value to a percentage of physical RAM, e.g. `prog +RTS -H256m -M95% -RTS'.
</p>
<p>
Bulat Ziganshin would like to be able to do the same with <tt>-c</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/750#changelog
http://ghc.haskell.org/trac/ghc/ticket/781
http://ghc.haskell.org/trac/ghc/ticket/781#781: GHCi on x86_64, cannot link to static data in shared libsWed, 31 May 2006 09:15:57 GMTguest<p>
System.Posix.getEnvironment fails on Linux 2.6.16-1.2108_FC4smp
with a segfault. (x86_64)
</p>
<pre class="wiki">[aleator@thoth HopenCV]$ ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.5.20060527, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base-1.0 ... linking ... done.
Prelude> :m +System.Posix.Env
Prelude System.Posix.Env> getEnv "USER"
Loading package unix-1.0 ... linking ... done.
Just "aleator"
Prelude System.Posix.Env> getEnvironment
Segmentation fault
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/781#changelog
http://ghc.haskell.org/trac/ghc/ticket/806
http://ghc.haskell.org/trac/ghc/ticket/806#806: hGetBufNonBlocking doesn't work on WindowsTue, 27 Jun 2006 05:52:35 GMTtitto@…<p>
All HAppS (<a class="ext-link" href="http://happs.org/HAppS/README.html"><span class="icon"></span>http://happs.org/HAppS/README.html</a>) applications fail with an internal error: asyncRead# when compiled with the -threaded option.
</p>
<p>
To reproduce the error:
</p>
<ul><li>compile any of the apps in the example subdirectory with -threaded and access it over the net (<a class="ext-link" href="http://localhost:8000"><span class="icon"></span>http://localhost:8000</a>).
</li></ul><p>
For example:
</p>
<p>
ghc --make -v -fallow-overlapping-instances -fglasgow-exts -threaded httpd.hs -o httpd
</p>
<p>
The same programs compiled without -threaded work fine.
</p>
<p>
Tested on Windows XP with latest SP/patches and gcc 6.4.2.
Let me know if you would like more info or the full compilation trace.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/806#changelog
http://ghc.haskell.org/trac/ghc/ticket/816
http://ghc.haskell.org/trac/ghc/ticket/816#816: Weird fundep behavior (with -fallow-undecidable-instances)Thu, 06 Jul 2006 19:04:37 GMTnibro<p>
I encounter a strange behavior with functional dependencies. Consider this program
</p>
<pre class="wiki">class Foo x y | x -> y where
foo :: x -> y
class Bar x y where
bar :: x -> y -> Int
instance (Foo x y, Bar y z) => Bar x z where
bar x z = bar (foo x) z
</pre><p>
Compiling (with 6.4.2, -fallow-undecidable-instances and -fglasgow-exts) I get the following error message:
</p>
<pre class="wiki">Foo.hs:12:0:
Context reduction stack overflow; size = 21
Use -fcontext-stack20 to increase stack size to (e.g.) 20
`$dBar :: Bar y z' arising from use of `bar' at Foo.hs:13:11-13
[... same thing 20 times ...]
`$dBar :: Bar y z' arising from use of `bar' at Foo.hs:13:11-13
`bar :: {bar at [y z]}' arising from use of `bar' at Foo.hs:13:11-13
When trying to generalise the type inferred for `bar'
Signature type: forall x y z. (Foo x y, Bar y z) => x -> z -> Int
Type to generalise: x -> z -> Int
In the instance declaration for `Bar x z'
</pre><p>
The declaration requires undecidable instances, but I doubt that the problem comes from that. What makes it even more weird is that I can get this to compile, and behave as expected, if I do one of a) declare an instance of Bar for any type, or
b) add an explicit type signature (foo x :: y) in the definition of Bar. The first seems weird since how could a different, unrelated instance affect the typeability of the second instance? The second, b), is weird since by the FD x -> y we should already know that foo x :: y.
</p>
<p>
Same behavior in GHC 6.4.1. Hugs (with -98 +O) accepts the code.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/816#changelog
http://ghc.haskell.org/trac/ghc/ticket/849
http://ghc.haskell.org/trac/ghc/ticket/849#849: Offer control over branch predictionTue, 08 Aug 2006 14:23:41 GMTsimonpj<p>
So now that GHC is so good at producing really fast low level code (see
ByteString benchmarks) we start to encounter low level gubbins where to
get the fastest possible code we need slightly more influence over
branch prediction.
</p>
<p>
In the code for ByteString's 'writeStrUp/Dn' functions we're doing a
tight loop writing bytes to memory.
</p>
<p>
The first version looks much like this:
</p>
<pre class="wiki">loop fp n off s = case next s of
Done -> return $! PS fp 0 off
Skip s' -> loop fp n off s'
Yield x s' -> do
withForeignPtr fp $ \p -> pokeByteOff p off x
loop fp n (off+1) s'
</pre><p>
When we get to the end of a memory block we need to double the size of
the memory block and carry on. So this adds an additional conditional
test into this loop.
</p>
<pre class="wiki">loop fp n off s = case next s of
Done -> trimUp fp n off
Skip s' -> loop fp n off s'
Yield x s'
| n == off -> realloc fp n off s' x
| otherwise -> do
withForeignPtr fp $ \p -> pokeByteOff p off x
loop fp n (off+1) s'
</pre><p>
There are dramatic differences between equivalent forms of code. Just by
reversing the order of the (n==off) test one form I can process 50Mb of
data in 0.20 seconds and in the other it takes 0.34 seconds.
</p>
<p>
That is:
</p>
<pre class="wiki"> | n == off -> realloc fp n off s' x
| otherwise -> do ...
</pre><p>
vs
</p>
<pre class="wiki"> | n /= off -> do ...
| otherwise -> realloc fp n off s' x
</pre><p>
I think that this is all down to branch prediction and the arrangement
of basic blocks. On a modern CPU correctly predicted branches are nearly
free while mis-predicted branches are very costly due to stalled
pipelines etc.
</p>
<p>
In gcc they have a branch prediction framework. It annotates
conditionals with prediction information. It then uses that during code
generation to do things like arranging basic blocks so that unlikely
blocks are moved out of line. It gets the prediction information from a
few sources. One is a simple static branch predictor, for example
branches back to to the beginning of a loop are likely to be taken and
branches to error functions are not. gcc even has a profile feedback
system to find the real probabilities of branches from a sample run of
the program. It also has a user annotation <tt>__builtin_expect()</tt> which many
C projects use in the form of a macro:
</p>
<pre class="wiki">if (unlikely(x==0)) { ...
</pre><p>
The Linux kernel uses this fairly heavily to move error handling code
out of the main 'fast path' code.
</p>
<p>
Anyway, so what I wish is that I could write something like:
</p>
<pre class="wiki">loop fp n off s = case next s of
Done -> {-# UNLIKELY #-}
trimUp fp n off
Skip s' -> loop fp n off s'
Yield x s'
| n == off -> {-# UNLIKELY #-}
realloc fp n off s' x
| otherwise -> do
withForeignPtr fp $ \p -> pokeByteOff p off x
loop fp n (off+1) s'
</pre><p>
The best approximating effect that I can use at the moment is to make
the unlikely realloc branch a local function in a where clause but mark
it with <tt> {-# NOINLINE #-} </tt> so that the code for the realloc case doesn't
pollute the tight loop for the normal fast case. Then the other
approximation is fiddling with the logic of the binary test and looking
at the benchmarks. The combination of these two techniques makes a
dramatic difference to the speed.
</p>
<p>
However I do need more control to do it reliably, while I was able to
make it work for writeStrUp, I could not find a combination to work for
writeStrDn - we loose about 50% performance when we add the realloc
branch. So a slightly more reliable method to hint at the likelihood of
conditionals would make this kind of low level code faster and easier to
write.
</p>
<p>
Some time ago as a quick hack I did add a branch prediction annotation
to the CMM conditional constructor. I only used it in the C backend to
turn it into uses of gcc's <tt>__builtin_expect()</tt>. I also didn't connect it
to the front end so I didn't have any high level static branch
prediction (which could be done by looking for branches with recursive
calls or calls to error etc). The only place I did actually use it was
in the heap check and stack check. I assumed that it would be
advantageous to predict heap and stack overflow branches as not taken.
It was only a quick hack - I didn't do any benchmarks to see if it had
any effect.
</p>
<p>
Anyway, just a thought, and of course not something we should be
thinking about 'til post 6.6.
</p>
<p>
Duncan
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/849#changelog
http://ghc.haskell.org/trac/ghc/ticket/855
http://ghc.haskell.org/trac/ghc/ticket/855#855: Improvements to SpecConstrWed, 09 Aug 2006 12:10:07 GMTsimonpj<p>
There are a series of possible improvemnts to <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/SpecConstr">SpecConstr</a>, described in
the source code. <tt>compiler/specialise/SpecConstr</tt>
</p>
<ul><li> Specialising for constant parameters
</li><li>Specialising for lambda parameters
</li><li>Two ideas to do with strictness that look more tricky
</li></ul><p>
Some of them look quite straightforward.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/855#changelog
http://ghc.haskell.org/trac/ghc/ticket/860
http://ghc.haskell.org/trac/ghc/ticket/860#860: CPP fails when a macro is used on a line containing a single quote characterThu, 10 Aug 2006 10:18:02 GMTketil@…<p>
CPP is nice when you need a quick-and-dirty solution, but one little stumbling block is
that macros are not expanded when the line contains a single quote character (as in function names ending in "prime" - let x' = MACRO x in...).
</p>
<p>
One solution is of course to break the line between the macro and the quote, but it'd be nice to have a CPP that was just a <em>bit</em> more clever.
</p>
<p>
-k
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/860#changelog
http://ghc.haskell.org/trac/ghc/ticket/881
http://ghc.haskell.org/trac/ghc/ticket/881#881: Improve space profiling for referencesThu, 31 Aug 2006 12:52:22 GMTsimonpj<p>
GHC's great space profiling tools don't appear to be much help when your
leaked memory is stored in references (IORefs, StablePtrs, etc). I had
a real-life case where the allocation profile showed me where the leaked
data came from, and I could guess that it was being held by some
reference, but I couldn't tell which one. Retainer set profiling showed
a big suspicious entry for "SYSTEM", but I couldn't find any way to
pinpoint the problem. (It ended up being a missing freeStablePtr in
hsgnutls, found by code inspection.)
</p>
<p>
Here's a contrived example that just allocates a bunch of IORefs:
</p>
<pre class="wiki"> import Control.Monad
import Data.IORef
main = repeatM (newIORef [1,2,3])
repeatM io = liftM2 (:) io (repeatM io)
</pre><p>
Retainer set profiling shows everything in "SYSTEM". None of the other
profiling methods say anything interesting either. What I'd like to
get, I think, is (1) your memory is being held in IORefs (2) allocated
by this cost center and (3) being retained by this cost center. I guess
I'm looking for something like a memory profiler for a traditional
language.
</p>
<p>
Andrew Pimlott
</p>
<p>
Simon Marlow comments: "The relevant predicate "is retainer" is pretty much built into the retainer profiler, and it returns true only for thunks if I recall correctly. Being able to tweak this, or maybe just install a better default would be an improvement.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/881#changelog
http://ghc.haskell.org/trac/ghc/ticket/888
http://ghc.haskell.org/trac/ghc/ticket/888#888: Implement the static argument transformationMon, 04 Sep 2006 16:37:57 GMTsimonpj<p>
The Static Argument transformation optimises
</p>
<pre class="wiki"> f x y = ....f x' y...
</pre><p>
into
</p>
<pre class="wiki"> f x y = let g x = ....g x'...
in g x
</pre><p>
Instead of passing <tt>y</tt> along unchanged, we make it into a free variable of a local function definition <tt>g</tt>.
</p>
<p>
Unfortunately, it's not always a win. Andre Santos gives a discussion, and quite a few numbers in <a class="ext-link" href="http://research.microsoft.com/%7Esimonpj/Papers/santos-thesis.ps.gz"><span class="icon"></span>his thesis</a>.
</p>
<p>
But sometimes it is a pretty big win. Here's the example that recently motivated me, which Roman Leshchinskiy showed me. You need the attached file Stream.hs, and then try compiling
</p>
<pre class="wiki"> import Stream
foo :: (a -> b) -> [a] -> [c]
foo f = mapL f
</pre><p>
Thus inspired, I think I have a set of criteria that would make the static arg transformation into a guaranteed win:
</p>
<ul><li>there is only one (external) call to the function
</li><li>OR its RHS is small enough to inline
</li><li>OR it is marked INLINE (?)
</li></ul><p>
So I'd like to try this idea out.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/888#changelog
http://ghc.haskell.org/trac/ghc/ticket/917
http://ghc.haskell.org/trac/ghc/ticket/917#917: -O introduces space leakThu, 28 Sep 2006 23:38:21 GMTclaus.reinke@…<p>
consider the following variant of a popular space problem
</p>
<pre class="wiki">initlast :: (()->[a]) -> ([a], a)
initlast xs = (init (xs ()), last (xs ()))
main = print $ case initlast (\()->[0..1000000000]) of
(init, last) -> (length init, last)
</pre><p>
the long list has been wrapped in abstractions to avoid
sharing, gaining constant space processing rather than
the space leak in the original code - see
</p>
<p>
<a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2006-September/018447.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-cafe/2006-September/018447.html</a>
</p>
<p>
<a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2006-September/018464.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-cafe/2006-September/018464.html</a>
</p>
<p>
this works nicely if compiled without -O, but unfortunately,
-O reintroduces the space leak (apparently lifting and sharing
the common and space-expensive subexpression).
</p>
<ol><li>I didn't see a ticket for this issue, so I wanted to record the example
</li></ol><ol start="2"><li>avoiding sharing isn't always possible, so it would be nice if one could
</li></ol><p>
"bypass" sharing in such cases. in the old g-machine, that might have
been as simple as introducing a pragma that tells the compiler to omit
the update after the eval in the code for some subexpression (so the
original application node would not be overwritten by the space-expensive
result, trading time for space). is there a chance for a similar trick
in GHC? so one might write code like this (handwaving:-):
</p>
<pre class="wiki">initlast :: [a] -> ([a], a)
initlast xs = (init ({-# COPY #-} xs), last ({-# COPY #-} xs))
main = print $ case initlast [0..1000000000] of
(init, last) -> (length init, last)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/917#changelog
http://ghc.haskell.org/trac/ghc/ticket/926
http://ghc.haskell.org/trac/ghc/ticket/926#926: infinite loop in ShutdownIOManager()Sat, 07 Oct 2006 13:42:40 GMTguest<p>
Hi,
</p>
<p>
I have found a way to 'hang' a DLL created using ghc-6.5.20061006 under Win32. This occurs when I dynamically load DLL built using GHC, call one of its exported functions that uses file IO and then exit my program without explicitly releasing the DLL first. I have uploaded a test application to <a class="ext-link" href="http://eeter.fi.tartu.ee/~mark/ghc_hang.zip"><span class="icon"></span>http://eeter.fi.tartu.ee/~mark/ghc_hang.zip</a> that demonstrates this issue.
</p>
<p>
I am not sure if I can call this a bug, as when I unload the DLL, everything works fine. But this does not happen in GHC-6.4.2 or older versions.
</p>
<p>
Regards,
Mark
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/926#changelog
http://ghc.haskell.org/trac/ghc/ticket/932
http://ghc.haskell.org/trac/ghc/ticket/932#932: Improve inliningWed, 11 Oct 2006 09:10:13 GMTsimonpj<p>
Currently the contruct
</p>
<pre class="wiki"> case (x# ># 0#) of ...
</pre><p>
attracts no argument discount for x#, which is silly.
</p>
<p>
The comment in CoreUnfold says:
</p>
<pre class="wiki"> PrimOpId op -> primOpSize op (valArgCount args)
-- foldr addSize (primOpSize op) (map arg_discount args)
-- At one time I tried giving an arg-discount if a primop
-- is applied to one of the function's arguments, but it's
-- not good. At the moment, any unlifted-type arg gets a
-- 'True' for 'yes I'm evald', so we collect the discount even
-- if we know nothing about it. And just having it in a primop
-- doesn't help at all if we don't know something more.
</pre><p>
But the right thing to do seems to be to fix interestingArg in SimplUtils so that it only thinks a primitive-typed thing is interesting if it knows its value (or some structure).
</p>
<p>
Here's the program that triggered this thought:
</p>
<pre class="wiki">import GHC.Word
import GHC.Base
import GHC.Prim
a `shiftRLT` b | b >=# 32# = int2Word# 0#
| otherwise = a `uncheckedShiftRL#` b
(W32# x#) `shift` (I# i#) =
{- we do an actual case analysis on i# to try to give us a discount -}
case i# of
{- For some bizzare reason removing the `shiftRLT` 0# makes the
inlining fail again -}
0# -> W32# (x# `shiftRLT` 0#)
_ ->
if i# >=# 0# then W32# (narrow32Word# (x# `shiftL#` i#))
else W32# (x# `shiftRLT` negateInt# i#)
x `shiftR` y = x `shift` (-y)
shift7 x = x `shiftR` 7
</pre><p>
roconnor@… initiated the thread
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/932#changelog
http://ghc.haskell.org/trac/ghc/ticket/947
http://ghc.haskell.org/trac/ghc/ticket/947#947: ghc -O space leak: CSE between different CAFsTue, 17 Oct 2006 01:04:27 GMTint-e@…<p>
Consider the following program for generating the 1,000,000th prime:
</p>
<pre class="wiki">module Main (main) where
sieve0 (n:ns) (p:ps)
| p*p == n = sieve0 (filter (\n -> n`mod`p /= 0) ns) ps
| otherwise = n:sieve0 ns (p:ps)
primes0 :: [Int]
primes0 = 3:sieve0 [5,7..] primes0
primes :: [Int]
primes = 2:3:sieve0 [5,7..] primes0
main = print $ primes !! 1000000
</pre><p>
The intention of the separate primes0 function is to limit the number of primes that need to be held in memory. Unfortunately, ghc -O combines the common subexpressions in primes0 and primes so this effort is wasted. The resulting program needs noticably more memory than required, as can be seen by replacing the definition of <tt>primes</tt> by
</p>
<pre class="wiki">primes = 2:3:sieve0 (iterate (2+) 5) primes0
</pre><p>
which prevents the CSE from happening.
</p>
<p>
Excerpt of <tt>+RTS -s</tt> output, original version:
</p>
<pre class="wiki">12,099,221,160 bytes allocated in the heap
279,720,116 bytes copied during GC
15,834,912 bytes maximum residency (6 sample(s))
</pre><p>
modified version that prevents CSE:
</p>
<pre class="wiki">127,736,408 bytes copied during GC (scavenged)
233,388 bytes copied during GC (not scavenged)
30,624 bytes maximum residency (1 sample(s))
</pre><p>
Tested with ghc 6.4.2 and a current (as of 2006-10-17) darcs ghc 6.5.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/947#changelog
http://ghc.haskell.org/trac/ghc/ticket/960
http://ghc.haskell.org/trac/ghc/ticket/960#960: Lexical call site stringTue, 24 Oct 2006 10:56:54 GMTpaul@…<p>
A function that returns the lexical call site of the current function when an exception occurs.
</p>
<p>
I'm thinking primarily of "head []", but the same principle would apply to other functions. A dynamic traceback is not necessarily possible in a lazy language, but when "head" gets called on an empty list there must be somewhere in the program that actually said "head", even if it was not evaluated at the time or included in a closure or something. That way when I get a "head: empty list" I don't need to grep my program for "head" calls: I know where head was called from and can start looking there.
</p>
<p>
Examples:
</p>
<ul><li>If I just have a function "foo = head" then it will report that the caller was "foo".
</li></ul><ul><li>If I have a function "bar x y = ..." and subsequntly say "baz x = bar (x * 2)" then an exception in "bar" will report the caller as "baz".
</li></ul><p>
I know there is a -x profiler option to get a sort of dynamic traceback, but I find it frequently just tells me the error is in "CAF.List", which isn't very informative.
</p>
<p>
I'm guessing at a difficulty of 1 week as I don't know the GHC internals. I'm guessing that the call site is going to have to be a hidden parameter passed in to each function call, or alternatively hard-coded when a function is in-lined.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/960#changelog
http://ghc.haskell.org/trac/ghc/ticket/989
http://ghc.haskell.org/trac/ghc/ticket/989#989: Build GHC on Windows using Microsoft toolchainMon, 06 Nov 2006 11:12:24 GMTsimonmar<p>
Create a Windows "native" port of GHC, i.e. one that uses the Microsoft toolchain instead of GCC and the GNU binutils. The main tasks are:
</p>
<ul><li>Convert the pretty printer in the i386 NCG to generate MS/Intel syntax
instead of AT&T syntax. We can then generate assembly code that MASM can
grok.
</li></ul><ul><li>Make the RTS compile with Microsoft's CL compiler. (this has been done in
the past, so shouldn't be too much work).
</li></ul><ul><li>Drop any dependencies on mingw32 functionality in the libraries.
</li></ul><ul><li>Make appropriate modifications to the driver, build system etc. We'd still
need Cygwin/MSYS for build tools (dropping dependency on GNU make is another task
entirely...)
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/989#changelog
http://ghc.haskell.org/trac/ghc/ticket/1009
http://ghc.haskell.org/trac/ghc/ticket/1009#1009: GHC Performance IndexFri, 17 Nov 2006 14:11:40 GMTsimonmar<p>
We want a lightweight way to detect when either (a) the compiler's performance changes, or (b) the performance of compiled code changes. This was triggerred by my noticing that the HEAD nightly builds seem somewhat slower than usual right now.
</p>
<p>
So the idea is pretty simple. We decide on a fixed set of nofib programs --intiially all of them, but we want the set to remain stable in the future -- and as part of the nightly build we time how long it takes to compile this set with a fixed set of flags (probably -O -fasm, to rule out changes in gcc). Then we time how long it takes to run all those programs, maybe 5 times each. Then we keep track of these two figures for every successful nightly build, and plot the results, giving us a nice way to track GHC's performance over time. We can go back and get some historical figures too. Of course the results are specific to a particular machine, so we'd have to keep track of results per nightly build machine or something.
</p>
<p>
So basically: some small changes to nofib to allow "just build everything" (I think even NoFibRuns=0 might do this), and to build a fixed set of programs (the set could be built into the nofib build system, no need to make it dynamic). And some way to collect the results and plot graphs.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1009#changelog
http://ghc.haskell.org/trac/ghc/ticket/1012
http://ghc.haskell.org/trac/ghc/ticket/1012#1012: ghc panic with mutually recursive modules and template haskellSun, 19 Nov 2006 02:03:49 GMTguest<p>
When compiling the files below using ghc --make Main.hs I get the following error:
</p>
<pre class="wiki">[1 of 5] Compiling ModuleA[boot] ( ModuleA.hs-boot, nothing )
[2 of 5] Compiling ModuleC ( ModuleC.hs, ModuleC.o )
[3 of 5] Compiling ModuleB ( ModuleB.hs, ModuleB.o )
Loading package base ... linking ... done.
Loading package template-haskell ... linking ... done.
ghc-6.6: panic! (the 'impossible' happened)
(GHC version 6.6 for powerpc-apple-darwin):
Maybe.fromJust: Nothing
</pre><p>
ModuleA.hs:
</p>
<pre class="wiki">module ModuleA where
import ModuleB
</pre><p>
ModuleA.hs-boot:
</p>
<pre class="wiki">module ModuleA where
</pre><p>
ModuleB.hs:
</p>
<pre class="wiki">{-# OPTIONS -fth #-}
module ModuleB where
import ModuleC
$(nothing)
</pre><p>
ModuleC.hs:
</p>
<pre class="wiki">module ModuleC where
import Language.Haskell.TH
import {-# SOURCE #-} ModuleA
nothing = return [] :: Q [Dec]
</pre><p>
Main.hs:
</p>
<pre class="wiki">module Main.hs
import ModuleA
main = return ()
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1012#changelog
http://ghc.haskell.org/trac/ghc/ticket/1016
http://ghc.haskell.org/trac/ghc/ticket/1016#1016: Avoidance of unaligned loads is overly conservativeMon, 20 Nov 2006 16:08:12 GMTigloo<p>
On alpha, mips, mipsel and arm we do loads in a way that is safe even if they are unaligned (see <tt>cLoad</tt> in <tt>compiler/cmm/PprC.hs</tt>). We need this when, for example, we read things with <tt>indexInt16OffAddr#</tt> from <tt>Addr#</tt>s in alex-generated lexers, but most of the time we know that the address is aligned appropriately so loads are slower than they need be.
</p>
<p>
A better way to do this would be to make Load a <tt>MachOp</tt> parameterised by whether it's known to be aligned or not. Likewise, Store should be a <tt>CallishMachOp</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1016#changelog
http://ghc.haskell.org/trac/ghc/ticket/1057
http://ghc.haskell.org/trac/ghc/ticket/1057#1057: Implicit parameters on breakpointsMon, 18 Dec 2006 10:42:59 GMTmnislaih<p>
Bring implicit parameters into the examine scope in breakpoints.
</p>
<p>
Test case is ghci.debugger break004
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1057#changelog
http://ghc.haskell.org/trac/ghc/ticket/1062
http://ghc.haskell.org/trac/ghc/ticket/1062#1062: Bad output from Text.PrettyPrint.HughesPJTue, 19 Dec 2006 23:13:53 GMTigloo<p>
This program:
</p>
<pre class="wiki">import Text.PrettyPrint.HughesPJ
ncat x y = nest 4 $ cat [ x, y ]
d1 = foldl1 ncat $ take 50 $ repeat $ char 'a'
d2 = parens $ sep [ d1, text "+" , d1 ]
main = print d2
</pre><p>
generates the output below. I haven't worked out what is expected, but this certainly doesn't look right to me (in particular, the space before the <tt>a</tt> on the third line of the output).
</p>
<pre class="wiki">% runghc pp1.hs | tr ' ' _
(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+___________________________________________________________________________________________________________________________________________________________________________________________________a
_a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a)
</pre><p>
The pp1 test goes on to say:
</p>
<pre class="wiki">This code used to print an infinite string, by calling 'spaces'
with a negative argument. There's a patch in the library now,
which makes 'spaces' do somehthing sensible when called with a negative
argument, but it really should not happen at all.
This output is not what is expected, becuase the
test "works" now, by virtue of a hack in HughesPJ.spaces.
I'm leaving this strange output here to remind us to look
at the root cause of the problem. Sometime.
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1062#changelog
http://ghc.haskell.org/trac/ghc/ticket/1087
http://ghc.haskell.org/trac/ghc/ticket/1087#1087: bang patterns with infix opsSat, 06 Jan 2007 01:41:07 GMTdons<pre class="wiki"> $ ghci -fbang-patterns
-- Ok
Prelude> let at a !b = False in at 1 2
False
Prelude> let (.!.) a !b = False in 1 .!. 2
False
-- ~ patterns are ok
Prelude> let a `at` ~b = False in at 1 2
False
Prelude> let a .!. ~b = False in 1 .!. 2
False
Prelude> let ~a .!. b = False in 1 .!. 2
False
-- Parse error if we combine bang patterns with infix decls:
Prelude> let a .!. !b = False in 1 .!. 2
<interactive>:1:10: parse error on input `!'
Prelude> let a `at` !b = False in at 1 2
<interactive>:1:11: parse error on input `!'
Prelude> let !a .!. b = False in 1 .!. 2
<interactive>:1:5: Parse error in pattern
</pre><p>
So looks like ops and infix declarations are missing a case for bang patterns.
</p>
<p>
-- Don
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1087#changelog
http://ghc.haskell.org/trac/ghc/ticket/1147
http://ghc.haskell.org/trac/ghc/ticket/1147#1147: Quadratic behaviour in the compacting GCWed, 14 Feb 2007 12:40:39 GMTsimonmar<p>
Run the following program under GHCi with <tt>+RTS -c -RTS</tt>:
</p>
<pre class="wiki">module Main where
break2 p (x:xs) = if p x then
([],x:xs)
else
let (b1,b2) = break2 p xs
in (x : b1, b2)
break2 p [] = ([],[])
surprise xs = b1 ++ "\n surprise " ++ b2
where
(b1,b2) = break2 (=='\n') xs
test n = length $ surprise $ [head (show i) | i <-[1..n] ] ++ "\n the end"
main = print $ test 1000000
</pre><p>
Notice how it hangs.
</p>
<p>
This is because of the call to <tt>get_threaded_info()</tt> in <tt>thread_PAP_payload()</tt> in the compacting GC. We have a lot of APs pointing to the same BCO, so the thread gets really long, and needs to be unravelled for every AP. One partial fix would be to cache the fun's info table in the spare field of an AP during the mark phase; this fixes the problem for APs, but not for PAPs (which don't have a spare field).
</p>
<p>
Related to this is the <tt>get_threaded_info()</tt> call in <tt>update_fwd_compact()</tt>, which is inefficient, but not quadratic. It would be nice to fix this too.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1147#changelog
http://ghc.haskell.org/trac/ghc/ticket/1158
http://ghc.haskell.org/trac/ghc/ticket/1158#1158: Problem with GADTs and explicit type signaturesTue, 20 Feb 2007 12:32:46 GMTguest<pre class="wiki">
{-# OPTIONS_GHC -fglasgow-exts #-}
module Main where
data Exp a where
Val :: a -> Exp b
App :: Exp a -> Exp b
instance Show (Exp a) where
show (Val _) = "Val"
show (App _) = "App"
class LiftToExp a b where
liftToExp :: a -> Exp b
instance LiftToExp (Exp a) a where
liftToExp = id
instance Floating a => LiftToExp a b where
liftToExp v = Val v :: Exp b
{-
Uncommenting the type signature below causes GHCi to fail to load the file:
test.hs:45:14:
Overlapping instances for LiftToExp a a11
arising from use of `liftToExp' at test.hs:45:14-24
Matching instances:
instance (Floating a) => LiftToExp a b -- Defined at test.hs:19:0
instance LiftToExp (Exp a) a -- Defined at test.hs:16:0
(The choice depends on the instantiation of `a, a11'
Use -fallow-incoherent-instances to use the first choice above)
In the first argument of `App', namely `(liftToExp x)'
In the expression: App (liftToExp x)
In the definition of `test': test x = App (liftToExp x)
However typing :t test at the GHCi prompt gives this exact signature.
Tested with GHC 6.6 (compiler and interpreter) under OS X 10.4.8 on an iMac G5.
-}
--test :: (LiftToExp a a1) => a -> Exp b
test x = App (liftToExp x)
main = putStrLn $ show (test (3.0::Float)::Exp Int)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1158#changelog
http://ghc.haskell.org/trac/ghc/ticket/1168
http://ghc.haskell.org/trac/ghc/ticket/1168#1168: Optimisation sometimes decreases sharing in IO codeFri, 23 Feb 2007 14:42:14 GMTsimonmar<p>
The simplifier is losing sharing in spectral/calendar, probably because we're being a bit fast-and-loose with eta-expanding State# lambdas. A quick look at the Core shows that <tt>calFor year</tt> is not shared across multiple executions.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1168#changelog
http://ghc.haskell.org/trac/ghc/ticket/1171
http://ghc.haskell.org/trac/ghc/ticket/1171#1171: GHC doesn't respect the imprecise exceptions semanticsSat, 24 Feb 2007 21:39:49 GMTneil<p>
Yhc bug 122 appears to be a GHC bug: <a class="ext-link" href="http://code.google.com/p/yhc/issues/detail?id=122"><span class="icon"></span>http://code.google.com/p/yhc/issues/detail?id=122</a> , discussed here: <a class="ext-link" href="http://thread.gmane.org/gmane.comp.lang.haskell.yhc/720"><span class="icon"></span>http://thread.gmane.org/gmane.comp.lang.haskell.yhc/720</a>
</p>
<p>
To reproduce:
Download and install Yhc two separate times, once doing "scons" to build, once doing "scons type=release". Follow the steps outlined in the above bug report with the standard version, and it gives the correct behaviour. Try again with the release version and it gives the wrong behaviour. GHC 6.4.2 works fine. The difference between the two is that type=release builds with -O, normal doesn't.
</p>
<p>
Changing the code slightly, by introducing "obvious" assert statements in Package.hs makes the bug go away. Creating reduced tests cases didn't get very far...
</p>
<p>
This has been replicated on Mac and Windows with GHC 6.6. If you have any further questions about the code then feel free to email me or the Yhc list. Marking as severity=major because silently doing something different is about as bad as they come.
</p>
<p>
Thanks to Thorkil for doing the detective work to track this down as far as GHC.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1171#changelog
http://ghc.haskell.org/trac/ghc/ticket/1176
http://ghc.haskell.org/trac/ghc/ticket/1176#1176: Infinite loop when printing error messageSun, 25 Feb 2007 20:14:46 GMTPaul_Berry@…<p>
I am trying to compile a file that has a known compile error. Ghc gets into an infinite loop trying to output the error message.
</p>
<p>
Here's the session (captured using EMACS shell):
</p>
<pre class="wiki">pberry@Dal:~/bridge_ghc_bug$ uname -a
Linux Dal 2.6.18-3-686 #1 SMP Mon Dec 4 16:41:14 UTC 2006 i686 GNU/Linux
pberry@Dal:~/bridge_ghc_bug$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
pberry@Dal:~/bridge_ghc_bug$ ghc -v --make main.hs
Glasgow Haskell Compiler, Version 6.6, for Haskell 98, compiled by GHC version 6.6
Using package config file: /usr/lib/ghc-6.6/package.conf
wired-in package base mapped to base-2.0
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0
wired-in package template-haskell mapped to template-haskell-2.0
Hsc static flags: -static
*** Chasing dependencies:
Chasing modules from: main.hs
Stable obj: []
Stable BCO: []
compile: input file main.hs
Created temporary directory: /tmp/ghc5182_0
*** Checking old interface for main:Main:
[1 of 1] Compiling Main ( main.hs, main.o )
*** Parser:
*** Renamer/typechecker:
main.hs:30:12:
No instance for (Show Rank)
arising from use of `show' at main.hs:30:12-19
Possible fix: add an instance declaration for (Show Rank)
In the first argument of `(~?=)', namely `show Ten'
In the expression: (show Ten) ~?= "T"
In the second argument of `($)', namely
`[(show Two) ~?= "2", (show Three) ~?= "3", (show Four) ~?= "4",
(show Five) ~?= "5", (show Six) ~?= "6", (show Seven) ~?= "7",
(show Eight) ~?= "8", (show Nine) ~?= "9", (show Ten) ~?= "T",
</pre><p>
At this point ghc goes into an (apparently) infinite loop outputting spaces. When I interrupt it using Ctrl-C, it says:
</p>
<pre class="wiki">*** Deleting temp files:
Deleting: /tmp/ghc5182_0/ghc5182_0.s
Warning: deleting non-existent /tmp/ghc5182_0/ghc5182_0.s
*** Deleting temp dirs:
Deleting: /tmp/ghc5182_0
</pre><p>
Here's the file main.hs:
</p>
<pre class="wiki">import System
import Test.HUnit
import Control.Monad
import Data.List
data Card = Card Rank Suit
data Suit = Clubs | Diamonds | Hearts | Spades
deriving (Enum, Eq)
data Rank = Two | Three | Four | Five | Six | Seven | Eight | Nine | Ten | Jack | Queen | King | Ace
deriving (Enum, Ord, Eq)
type Hand = [Card]
hand :: String -> Hand
hand = undefined
main = undefined
allTests = test $
[show Two ~?= "2"
,show Three ~?= "3"
,show Four ~?= "4"
,show Five ~?= "5"
,show Six ~?= "6"
,show Seven ~?= "7"
,show Eight ~?= "8"
,show Nine ~?= "9"
,show Ten ~?= "T"
,hand "AK76543/32/AK2/3" ~?= exampleHand
]
where exampleHand = []
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1176#changelog
http://ghc.haskell.org/trac/ghc/ticket/1192
http://ghc.haskell.org/trac/ghc/ticket/1192#1192: GHC-only IOErrorType constructors, and is*Error(Type) functionsSun, 04 Mar 2007 13:22:45 GMTigloo<p>
Currently we don't have <tt>is*Error</tt> and <tt>is*ErrorType</tt> functions for those constructors of <tt>IOErrorType</tt> below the <tt>GHC only</tt> comment. It would be nice to add them, but better still to make the constructors known to the other implementations first.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1192#changelog
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/1231
http://ghc.haskell.org/trac/ghc/ticket/1231#1231: deprecation warnings are reported too oftenFri, 16 Mar 2007 11:18:36 GMTmalcolm.wallace@…<p>
Not so much a bug, more an annoyance.
</p>
<p>
In some code which is designed to work on multiple compiler platforms, there are some system dependencies such as the name/location of non-standard libraries. Accordingly, I gather all such deps into a single module SysDeps.hs, which is heavily reliant on cpp #ifdefs, but whose only purpose is to re-export the non-standard entities needed by the rest of the project. So far so good. Now it turns out that ghc-6.6 has deprecated some of the non-standard libraries. Fair enough, I would expect to see the deprecation warnings when I compile SysDeps.hs. But in fact, I see multiple deprecation warnings - one for every deprecated entity, used in any module. So instead of seeing 5 or so warnings, nicely localised to a single module, I see 40 or so, smeared out across the whole project.
</p>
<p>
An example:
</p>
<pre class="wiki">Import.hs:9:28:
Warning: Deprecated use of `unpackPS'
(imported from SysDeps, but defined in Data.PackedString):
use Data.ByteString, Data.ByteString.Char8, or plain String.
</pre><p>
As you can see, the warning mechanism is aware that it is doing a transitive closure over imports. But really, I'd prefer it not to, and instead to report the deprecation only in the directly-importing module.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1231#changelog
http://ghc.haskell.org/trac/ghc/ticket/1262
http://ghc.haskell.org/trac/ghc/ticket/1262#1262: RecursiveDo in Template HaskellTue, 03 Apr 2007 02:38:24 GMTphilip.weaver@…<p>
I really want mdo support in Template Haskell! Thanks!
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1262#changelog
http://ghc.haskell.org/trac/ghc/ticket/1273
http://ghc.haskell.org/trac/ghc/ticket/1273#1273: would like to print partial application values when at a breakpointThu, 12 Apr 2007 16:29:26 GMTguest<p>
I'd like to be able to examine partial application values when at a breakpoint.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1273#changelog
http://ghc.haskell.org/trac/ghc/ticket/1290
http://ghc.haskell.org/trac/ghc/ticket/1290#1290: ghc runs preprocessor too muchThu, 26 Apr 2007 10:24:21 GMTguest<p>
When an external preprocessor has been specified with -F -pgmF, and then using ghc --make, ghc runs the preprocessor on every .hs file, even those for which compilation is skipped. This seem unnecessary and it slows down recompilation significantly when you have many files.
</p>
<blockquote>
<p>
-- Lennart
</p>
</blockquote>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1290#changelog
http://ghc.haskell.org/trac/ghc/ticket/1307
http://ghc.haskell.org/trac/ghc/ticket/1307#1307: Warning refers to code not in the sourceFri, 27 Apr 2007 12:17:51 GMTguest<p>
Here's some source:
</p>
<pre class="wiki">toXML = toXMLEx (Just . cap)
where cap ('_':cs) = cap cs
cap (c:cs) = toUpper c : cs
cap "" = ""
</pre><p>
And here's a warning that refers to notElem which I've not used:
</p>
<pre class="wiki">../Gmag/Paradise/Addins/XML/Prim.hs:47:8:
Warning: Pattern match(es) are non-exhaustive
In the definition of `cap':
Patterns not matched: #x with #x `notElem` [""#]
</pre><blockquote>
<p>
-- Lennart
</p>
</blockquote>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1307#changelog
http://ghc.haskell.org/trac/ghc/ticket/1308
http://ghc.haskell.org/trac/ghc/ticket/1308#1308: Type signature in warning is wrongFri, 27 Apr 2007 12:32:49 GMTguest<p>
Here's some source:
</p>
<pre class="wiki">autoChart = do
xchart Nothing Nothing Nothing Nothing Nothing Nothing
xchart lbl lgd xmin xmax ymin ymax = do
...
</pre><p>
And the warnings related to these:
</p>
<pre class="wiki"> Warning: Definition but no type signature for `autoChart'
Inferred type: autoChart :: t View
Warning: Definition but no type signature for `autoChart'
Inferred type: autoChart :: t View
Inferred type: xchart :: forall (m :: * -> *).
(Monad m) =>
Maybe EString
-> Maybe Position
-> Maybe (E Double)
-> Maybe (E Double)
-> Maybe (E Double)
-> Maybe (E Double)
-> m View
</pre><p>
The warning for autoChart is clearly wrong since there should be a context 'Monad t'.
</p>
<blockquote>
<p>
-- Lennart
</p>
</blockquote>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1308#changelog
http://ghc.haskell.org/trac/ghc/ticket/1311
http://ghc.haskell.org/trac/ghc/ticket/1311#1311: newtypes of unboxed types disallowed - documentation bug and/or feature requestSun, 29 Apr 2007 17:32:19 GMTIsaac Dupree<p>
Tested in 6.6.1 and today's 6.7 (which claims to be version 6.7.20070418),
</p>
<p>
<tt>newtype FastBool = FastBool Int#</tt>
</p>
<p>
doesn't work. However this is not documented in the unboxed-types documentation in the User's Guide that lists similar restrictions <a href="http://www.haskell.org/ghc/docs/latest/html/users_guide/primitives.html">http://www.haskell.org/ghc/docs/latest/html/users_guide/primitives.html</a>
</p>
<p>
Similarly (maybe), in phantom type arguments, even in GADTs where kind inference could be at work
</p>
<p>
<tt>data Boo a where Boo :: Int# -> Boo Int#</tt>
</p>
<p>
doesn't work.
</p>
<p>
I tried <tt>newtype ( FastBool :: # ) = ...</tt> , and <tt>data Boo ( a :: # ) where...</tt> , which just confused GHC.
</p>
<p>
Is there a reason that coercions of unlifted types shouldn't work, or is it just unimplemented? (inspired by looking at GHC's
compiler/utils/FastTypes.lhs and thinking that using newtypes instead of type synonyms in places like that would improve type-safety)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1311#changelog
http://ghc.haskell.org/trac/ghc/ticket/1316
http://ghc.haskell.org/trac/ghc/ticket/1316#1316: add warning for local type signatures that use the same type variable names as outer type signaturesTue, 01 May 2007 22:09:19 GMTIsaac Dupree<p>
for a (poor) example,
</p>
<pre class="wiki">f :: a -> a
f x = x
where
g :: a --this is (forall x. x) not the 'a' from f's type signature
-- So, warn about this signature.
g = undefined
</pre><p>
Because it is likely to be confusing, as well as interfering with any possibility of the type variables being considered scoped by default. In fact, this may be a helpful/explanatory message in cases where there will also be a type error due to the type variables not actually being scoped. (although, detecting those cases particularly and giving a recommended solution for how to give such a type signature, would be a more difficult endeavor (what to recommend?))
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1316#changelog
http://ghc.haskell.org/trac/ghc/ticket/1318
http://ghc.haskell.org/trac/ghc/ticket/1318#1318: add warning for prefix negate operator and flag to replace it with negative numeric literalsTue, 01 May 2007 23:41:35 GMTIsaac Dupree<p>
This is tracking a few things relating to the notion that Haskell's single prefix operator, "<tt>-</tt>", should not exist and "<tt>-1</tt>" should parse as a single token anyway. See <a class="ext-link" href="http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/11954"><span class="icon"></span>http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/11954</a>
</p>
<p>
If there is a LANGUAGE option for this, what should it be called; and what should the ghc flags be called? Should turning off prefix negation and turning on negative numeric literals be separately controllable? This sort of question (exactly what should be implemented) is probably half the difficulty here.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1318#changelog
http://ghc.haskell.org/trac/ghc/ticket/1330
http://ghc.haskell.org/trac/ghc/ticket/1330#1330: Impredicativity bug: Church2 test gives a rather confusing error with the HEADSat, 05 May 2007 15:23:10 GMTigloo<p>
The Church2 test gives a rather confusing error with the HEAD:
</p>
<pre class="wiki">Church2.hs:27:14:
Couldn't match expected type `CNat'
against inferred type `(a -> a) -> a -> a'
Expected type: CNat -> CNat
Inferred type: CNat -> CNat
In the first argument of `n', namely `(mul m)'
In the expression: n (mul m) n1
</pre><p>
In particular the lines
</p>
<pre class="wiki"> Expected type: CNat -> CNat
Inferred type: CNat -> CNat
</pre><p>
are confusing, and I'm not sure why it's giving two expected/inferred pairs of types.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1330#changelog
http://ghc.haskell.org/trac/ghc/ticket/1349
http://ghc.haskell.org/trac/ghc/ticket/1349#1349: Generalise the ! and UNPACK mechanism for data types, to unpack function argumentsFri, 11 May 2007 12:51:40 GMTsimonpj<p>
See this thread:
</p>
<blockquote>
<p>
<a class="ext-link" href="http://www.nabble.com/More-speed-please!-t3411977.html"><span class="icon"></span>http://www.nabble.com/More-speed-please!-t3411977.html</a>
</p>
</blockquote>
<p>
Briefly the idea is to allow
</p>
<pre class="wiki"> data T = MkT (!Int -> Bool)
</pre><p>
to make a <tt>MkT</tt> hold strict functions only. Anyone unpacking a <tt>MkT</tt> can assume the function is strict; and anyone building a <tt>MkT</tt> gets a strictness wrapper aound whatever function they supply, so even if they supply a lazy function, it's made strict.
</p>
<p>
Seems like a natural generalisation of the existing strictness and UNPACK mechanism for data types.
</p>
<p>
Lots of details in the thread above.
</p>
<p>
Simon
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1349#changelog
http://ghc.haskell.org/trac/ghc/ticket/1365
http://ghc.haskell.org/trac/ghc/ticket/1365#1365: -fbyte-code is ignored in a OPTIONS_GHC pragmaSat, 19 May 2007 18:19:08 GMTmnislaih<p>
When loading a bunch of modules in ghci with <em>-fobject-code</em>, it seems reasonable to be expect that individual <em>GHC_OPTIONS -fbyte-code</em> pragmas will have the effect of loading individual modules via the bytecode backend.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1365#changelog
http://ghc.haskell.org/trac/ghc/ticket/1371
http://ghc.haskell.org/trac/ghc/ticket/1371#1371: Add -O3Tue, 22 May 2007 08:16:19 GMTsimonmar<p>
It has been suggested that we should have an -O3 that trades off code size for speed. Things that we could do include bumping the threshold for some optimisations (inlining, <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/SpecConstr">SpecConstr</a>, LiberateCase), and perhaps inlining some operations in the back-end.
</p>
<p>
Of course we should measure the effect of various settings on nofib/nobench and pick a good combination.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1371#changelog
http://ghc.haskell.org/trac/ghc/ticket/1377
http://ghc.haskell.org/trac/ghc/ticket/1377#1377: GHCi debugger tasksFri, 25 May 2007 08:52:26 GMTsimonmar<p>
I'm collecting all these together into one ticket for now. Later we might split off individual tasks. Please update the description if you complete one of these.
</p>
<h2 id="easy">easy</h2>
<ul><li>Autocompletion for :break only provides names, not modules
</li></ul><h2 id="moderate">moderate</h2>
<ul><li>for each breakpoint we should retain the declpath constructed by the coverage pass. This would let us
show the enclosing binding(s) for each breakpoint in the UI (eg. "Stopped in M.f (M.hs:40:23-28)").
</li></ul><ul><li>:force should catch exceptions, so [1,2,undefined] would display as <tt>[1,2,< exception >]</tt>
</li></ul><ul><li>show variables with unboxed types.
</li></ul><ul><li>tabs go wrong with :list (but only for .lhs files, because unlit does tab expansion... duh)
</li></ul><h2 id="unknownorrequirethinkingabout">unknown, or require thinking about</h2>
<ul><li>Some kind of "step over" or "next" command is needed.
</li></ul><ul><li><tt>:break <qualified name></tt> only works if the name is exported can/should we relax this?
</li></ul><ul><li>perhaps we should have a :watch command, that could be used to save variables for future inspection (they wouldn't get
thrown away by :continue)
</li></ul><ul><li>We can disable a breakpoint with ":set stop N :continue", but this still prints out the breakpoint info when we stop.
Should we print the info only if there were no commands?
</li></ul><ul><li>Revert to adding tick information to the BCO directly, and remove the byte code instructions for breaks. I'm not sure that this is worth it. In some ways the implementation based on a byte code instruction is a little cleaner than adding breaks on BCOs directly. Though the bc instruction method may be a little slower than the other way.
</li></ul><ul><li>Flag to disable breakpoints?
</li></ul><ul><li>When we restore the interactive context on resume, we throw away any new bindings made since the breakpoint. Can this
be fixed?
</li></ul><ul><li>threads and breakpoints.
</li></ul><ul><li>if a :force results in a breakpoint, we should treat it as we do other evaluations. (currently we get
"<strong>* Ignoring breakpoint").
</strong></li></ul><p>
</p>
<ul><li>It's a bit strange that in "f = e" you don't get a breakpoint covering the whole binding, but in "f x = e" you do.
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1377#changelog
http://ghc.haskell.org/trac/ghc/ticket/1379
http://ghc.haskell.org/trac/ghc/ticket/1379#1379: Allow breakpoints and single-stepping for functions defined interactivelyFri, 25 May 2007 20:49:06 GMTMichael D. Adams<p>
Steps to reproduce (from ghc-HEAD sources for 25 May 2007):
</p>
<pre class="wiki">Prelude> let fib n = if n < 2 then 1 else fib (n-1) + fib (n-2)
Prelude> let main = print $ fib 30
Prelude> :break fib
ghc-6.7.20070515: panic! (the 'impossible' happened)
(GHC version 6.7.20070515 for i386-unknown-linux):
nameModule fib{v apa}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Prelude>
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1379#changelog
http://ghc.haskell.org/trac/ghc/ticket/1388
http://ghc.haskell.org/trac/ghc/ticket/1388#1388: Newbie help featuresMon, 28 May 2007 14:49:25 GMTguest<p>
Often a newbie comes to #haskell and asks why something doesn't work in ghci.
There are at least two cases:
</p>
<p>
"why doesn't type Bar = (Char, Int) work"?
</p>
<blockquote>
<p>
and
</p>
</blockquote>
<p>
"why doesn't f = 1 work?" (that is function definitions)
</p>
<p>
It wouldn't be much work to recognize these cases and then give the user some hints on putting those definitions into a file, etc.
</p>
<p>
Another case where error messages can be improved is the following:
</p>
<p>
type Foo = (char, int) -- the intention is clear, but the error message might not be clear to a new user. Suggestion: when the parsed type variables are the same modulo case to an existing core type(Int, Bool, Array, etc) and Foo doesn't take those type parameters, tell the user he needs to use proper casing.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1388#changelog
http://ghc.haskell.org/trac/ghc/ticket/1399
http://ghc.haskell.org/trac/ghc/ticket/1399#1399: better support for developing threaded applications in ghciThu, 31 May 2007 14:03:18 GMTguest<p>
The haskell threads model has the appealingly simple property that the main thread determines the lifetime of your program. Once the main thread completes, all other threads are killed.
</p>
<p>
However this doesn't apply when iteratively developing at the ghci command-line. If, for example, you run <tt>main</tt> from the ghci prompt, you regain control of the prompt when your main thread terminates, but any threads spawned by it will keep running. This is particularly irksome if some of them hold onto OS resources (e.g. listening TCP sockets) as you find you can't run your code more than once due to resource issues.
</p>
<p>
It is possible to solve this problem explicitly by killing all the threads yourself at the end of <tt>main</tt>, but that amounts to adding a special <tt>ghci</tt> workaround to your code, because you wouldn't need that to compile as a standalone application.
</p>
<p>
I don't have a specific proposal on the best solution. One would be to alter <tt>ghci</tt>'s semantics so that after the completion of every interactively entered <tt>IO a</tt> action you reap all new threads that have been created. The disadvantage of this would be that it inhibits some interesting kinds of debugging exploring where you deliberately fork some threads from ghci and then communicate with them.
</p>
<p>
A more general solution would be some kind of <tt>:command</tt> to run either with-or-without the reaper-like function as preferred.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1399#changelog
http://ghc.haskell.org/trac/ghc/ticket/1400
http://ghc.haskell.org/trac/ghc/ticket/1400#1400: :set +r doesn't work for interpreted modulesThu, 31 May 2007 14:58:51 GMTiampure@…<p>
I expect
</p>
<pre class="wiki">a = trace "a" 1
</pre><p>
and then evaluating a repeatedly to show:
"a"
1
</p>
<p>
as a result. ghci seems to do this, but with larger programs this doesn't appear to happen.
</p>
<p>
I guess it's an implementation detail in that expressions don't "need" to be evaluated twice, but for debugging purposes it's vital that it does.
</p>
<p>
I want that the first run of an algorithm produces the same trace as any subsequent one. Especially when one uses the 6.7 debugger this is an issue. Essentially, I need to load another module first and then the module I am interested in and then set the breakpoints again. This is a UI nightmare.
</p>
<p>
The option +r "revert top-level expressions after each evaluation" seems to indicate that should do what I want, but it doesn't.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1400#changelog
http://ghc.haskell.org/trac/ghc/ticket/1404
http://ghc.haskell.org/trac/ghc/ticket/1404#1404: allow more type signaturesFri, 01 Jun 2007 19:55:37 GMTIsaac Dupree<p>
(idea triggered by <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/393" title="feature request: functions without implementations (new)">#393</a>)
</p>
<p>
Allow multiple copies of a type-signature in a module, such that it is an error if they're not equivalent, but they don't have to be syntactically equal (
<tt>f :: ShowS</tt>
<tt>f :: String -> String</tt>
is okay).
</p>
<p>
It would also be nice to allow any name in scope at top-level (even if imported) to be given a type signature. But that raises a question: can these type signatures give a more specific type than that of the raw imported function, the way normal function type signatures can with regards to their implementation?
</p>
<p>
Use cases: (1. making sure multiple implementations give the same interface, generally varying by #ifdef) (2. asserting that something's type can be specified in two different weird ways). I don't really want to abandon having a type-signature right above every function definition even if it is a duplicate.
</p>
<p>
(1.) would be fixed by allowing type signatures in export lists instead. I suppose these could be more restrictive than in the module and not affect the module, e.g.
</p>
<pre class="wiki">module X (idN :: Int -> Int, true) where
idN n = n
true :: Bool
true = idN True
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1404#changelog
http://ghc.haskell.org/trac/ghc/ticket/1405
http://ghc.haskell.org/trac/ghc/ticket/1405#1405: Make ghc (stage1) be compilable by non-GHCFri, 01 Jun 2007 21:04:04 GMTIsaac Dupree<p>
This depends a bit on the existence of a good-enough non-GHC compiler. Possibility to do recursively dependent modules (I think) presently rules out everything except JHC, which is not entirely working yet. Also pattern guards might need to be implemented in that compiler. Maybe for testing, a ghc that doesn't define <span class="underline">GLASGOW_HASKELL</span> (and doesn't use ghc-specific flags ?? possibly a wrapper script of some sort) could be used too.
</p>
<p>
See <a class="ext-link" href="http://thread.gmane.org/gmane.comp.lang.haskell.cvs.ghc/20962"><span class="icon"></span>http://thread.gmane.org/gmane.comp.lang.haskell.cvs.ghc/20962</a> ... GHC also uses things like IORefs, (unsafeCoerce? only in stage2 I think) that everyone provides, but would still be good to document.
</p>
<p>
I'm working on this now, we'll see how far I get --Isaac
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1405#changelog
http://ghc.haskell.org/trac/ghc/ticket/1409
http://ghc.haskell.org/trac/ghc/ticket/1409#1409: Allow recursively dependent modules transparently (without .hs-boot or anything)Mon, 04 Jun 2007 13:42:28 GMTIsaac Dupree<p>
Essentially, compile strongly-connected sets of modules like single modules are compiled (they have to have the same default and monomorphism-restriction, so it is like compiling one module, after the module/import fixpoint and name resolution are done).
</p>
<p>
This can increase the amount of recompilation necessary compared to using .hs-boot files, so it is probably desirable to still allow those. Of course, manually keeping .hs-boot files and {-#SOURCE#-} pragmas around (and synchronized with the real code) is a nuisance (though informative if one cares about minimizing the amount of recursion). I suspect that there can be situations where one level of export-subsets via .hs-boot files is not sufficient... (which would be one reason it wouldn't be easy to "just" treat a subset of each .hs file as its .hs-boot).
</p>
<p>
When not using --make mode, ghc would have to find the minimal module cycles somehow, and put just one ".hi-boots" or ".his", and .o I think, file somewhere (next to an arbitrary one of the modules I guess) in order that the compilation isn't repeated pointlessly for each module. And deal with which compiler flags are used. Maybe better not to allow it without --make.
</p>
<p>
In --make mode, such hackery should not be needed. This might also help deal with (work around?) such existing bugs with recursive modules and --make: <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/930" title="bug: ghc-6.6: panic! (the 'impossible' happened) mkWWcpr: not a product ... (closed: fixed)">#930</a> , <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1072" title="bug: Core Lint Errors: in result of Desugar (closed: fixed)">#1072</a> , <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1133" title="bug: auto-derivation of Enum is disallowed with recursive imports (closed: fixed)">#1133</a> . The modules having different OPTIONS_GHC or LANGUAGE pragmas might still be tricky or impossible to accept, depending which ones they are and how much implementation effort it's worth investing in allowing that. (Although, class instances being overlappable might be advantageous to have implemented a per-class not per-module specification anyway, for example, so pragmas that affect less than the whole module could be added more easily.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1409#changelog
http://ghc.haskell.org/trac/ghc/ticket/1420
http://ghc.haskell.org/trac/ghc/ticket/1420#1420: Automatic heap profile intervalsFri, 08 Jun 2007 17:56:52 GMTguest<p>
When doing heap profiling it is sometimes hard to know what a good sampling interval is. Make it too small and it takes forever, make it too coarse and the resolution is bad.
In hbc the default setting was to automatically adjust the interval. It starts out very small, but as samples accumulate it gets larger and larger. This is a nice compromise.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1420#changelog
http://ghc.haskell.org/trac/ghc/ticket/1444
http://ghc.haskell.org/trac/ghc/ticket/1444#1444: Template Haskell: add proper support for qualified names in non-splicing applicationsThu, 21 Jun 2007 02:34:17 GMTSamB<p>
For the uninitiated, Derive is an application of Template Haskell that can generate external Haskell code (depending on how you use it) instead of having it spliced into a module. Template Haskell was not designed for this, and it shows in the handling of qualified names. For example:
</p>
<pre class="wiki">Prelude> '[]
GHC.Base.[]
Prelude> 'True
GHC.Base.True
Prelude> '(*)
GHC.Num.*
Prelude Data.Array.Unboxed> ''UArray
Data.Array.Base.UArray
</pre><p>
It would be nice if Template Haskell could instead use public names, where available, so that Derive and similar tools would be able to use qualified names (and the quoting syntax without fear of their ending up pointing into the middle of no-mans-land, or even GHC-only land.
</p>
<p>
This would also mean that users of Derive via TH splicing wouldn't need to import so many modules that the derivings depend on.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1444#changelog
http://ghc.haskell.org/trac/ghc/ticket/1451
http://ghc.haskell.org/trac/ghc/ticket/1451#1451: Provide way to show the origin of a constraintFri, 22 Jun 2007 11:25:14 GMTiampure@…<p>
For a complex type (A b, C d, E e) => Something a b e -> Int, provide a way to given the query:
where does A b come from? Respond with the line number of a function that causes that constraint. This should of course also work for non-Haskell 98 constraints.
</p>
<p>
This issue comes up when one by accident calls a function in the wrong layer of a monadic transformer stack.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1451#changelog
http://ghc.haskell.org/trac/ghc/ticket/1466
http://ghc.haskell.org/trac/ghc/ticket/1466#1466: Stack check for AP_STACKThu, 28 Jun 2007 09:43:51 GMTsimonmar<p>
This is a bug I uncovered in the interpreter, that I think is also present in the compiler.
</p>
<p>
When compiling code for a function or thunk, we aggregate the stack usage from case continuations up to the top of the function/thunk and perform a single stack check. This normally works fine: we know the maximum amount of stack that will be required in the evaluation of this function/thunk, and we check for it up front.
</p>
<p>
However, this goes wrong if the evaluation is suspended by an asynchronous exception: the stack is broken into chunks and stored in <tt>AP_STACK</tt> objects, which may later be resumed. On resumption, we might not have enough stack any more: the code might now be running on another stack entirely, even.
</p>
<p>
Our proposed solution is as follows:
</p>
<ul><li>Continuations that require more than a certain amount of stack (say 4k)
do their own stack checks.
</li></ul><ul><li>an AP_STACK object records the amount of stack available at the time it
was suspended, if the amount is <4k. On resumption of an AP_STACK, we
ensure that at least this amount of stack is available. (there's a
spare half-word field in AP_STACK that we can use for this).
</li></ul><p>
The 4k limit is important: it puts a bound on the amount of stack growth due to evaluating an AP_STACK. Essentially the 4k limit is large enough that it almost never happens.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1466#changelog
http://ghc.haskell.org/trac/ghc/ticket/1475
http://ghc.haskell.org/trac/ghc/ticket/1475#1475: Adding imports and exports with Template HaskellSun, 01 Jul 2007 11:43:16 GMTigloo<p>
(wished for by Adrian Hey in <a class="ext-link" href="http://www.haskell.org/pipermail/template-haskell/2007-June/000598.html"><span class="icon"></span>http://www.haskell.org/pipermail/template-haskell/2007-June/000598.html</a>)
</p>
<p>
It would be useful to be able to add module exports with TH, although I'm not sure exactly how it would be done. Perhaps something like
</p>
<pre class="wiki">$( do n <- newName "foo"
let d = funD n ...
addExport (varE n)
return [d]
</pre><p>
but at the point we call <tt>addExport</tt> the typechecker doesn't know that there will be a declaration for the name.
</p>
<p>
Less useful, as TH names include the package and module of the name's definition, is the ability to add module imports. However, this can still be used to get a kind of dynamic binding effect, either with <tt>mkName</tt>'s names or plain Haskell code, e.g.:
</p>
<pre class="wiki">$( addImport (if ... then '''Data.ByteString else '''Data.ByteString.Lazy)
(mkName "BS") )
foo :: BS.ByteString
foo = BS.append ...
</pre><p>
(we'd actually probably want a datatype that mirrors Haskell import decls more closely).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1475#changelog
http://ghc.haskell.org/trac/ghc/ticket/1477
http://ghc.haskell.org/trac/ghc/ticket/1477#1477: ghci shouldn't link entire packageSun, 01 Jul 2007 13:09:30 GMTigloo<p>
In this thread: <a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-users/2007-January/011839.html"><span class="icon"></span>http://www.haskell.org/pipermail/glasgow-haskell-users/2007-January/011839.html</a>
Alistair Bayley requests that ghci only link against parts of a package that are actually needed (like ld does) as:
</p>
<pre class="wiki">With Takusen, all modules, including the DBMS-specific modules, are
compiled into a single library. At present we have 3 DBMS's: Sqlite,
Oracle, and PostgreSQL. For example, suppose you had just the Oracle
DBMS client libraries installed, and you write a program which only uses
the Oracle modules from Takusen. When you link, the gnu ld program
attempts to resolve the symbols in only the modules that you've used.
You don't need to have PostgreSQL or Sqlite installed, and the linker
ignores these modules from the package archive. This is quite nice,
because we can distribute the entire library as a single package, and it
will work even if the user does not have all of the DBMS client
libraries installed.
In contrast, when ghci (or runhaskell) attempts to link it tries to
resolve all of the symbols in the PostgreSQL and Sqlite modules, and
fails because you don't have them installed.
The result is that a user of Takusen can't easily use the library with
ghci/runhaskell "out of the box", unless they have the full set of DBMS
client libraries installed. There are a couple of workarounds, but
they're both a bit fiddly, so it'd be nicer (from my POV) if the ghci
linker behaved like gnu ld.
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1477#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/1498
http://ghc.haskell.org/trac/ghc/ticket/1498#1498: Optimisation: eliminate unnecessary heap check in recursive functionFri, 06 Jul 2007 08:47:42 GMTsimonmar<p>
See <a class="ext-link" href="http://www.haskell.org/pipermail/cvs-ghc/2007-July/036496.html"><span class="icon"></span>http://www.haskell.org/pipermail/cvs-ghc/2007-July/036496.html</a>
</p>
<p>
In a basic block consisting of some primitive cases, in which only some branches require heap, we could push the heap check into the branches as long as the primitive operations are safe to repeat, and the stack has not been modified. This might save a heap check in the common recursive case, which could be a significant win.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1498#changelog
http://ghc.haskell.org/trac/ghc/ticket/1526
http://ghc.haskell.org/trac/ghc/ticket/1526#1526: -fobject-code doesn't apply to expressions typed at the promptThu, 12 Jul 2007 07:32:40 GMTsorear<p>
While looking to see if I could easily fix <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1525" title="feature request: :browse shouldn't print single-constructor data definitions twice (closed: fixed)">#1525</a> myself, I saw a suspicious modification to the unboxed tuples error; examining more closely:
</p>
<pre class="wiki">stefan@stefans:~/qhc/qhc-desugar/Qhc/TypeCheck$ ghci
Loading package base ... linking ... done.
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.7.20070612, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Prelude> :set -fglasgow-exts
Prelude> let foo x y = (# x, y #)
Error: bytecode compiler can't handle unboxed tuples.
Possibly due to foreign import/export decls in source.
Workaround: use -fobject-code, or compile this module to .o separately.
Prelude> :set -fobject-code
Prelude> let foo x y = (# x, y #)
Error: bytecode compiler can't handle unboxed tuples.
Possibly due to foreign import/export decls in source.
Workaround: use -fobject-code, or compile this module to .o separately.
Prelude>
</pre><p>
so the suggested workaround doesn't actually work. I can certainly imagine a model of GHC compilation where the NCG doesn't support anonymous modules; in which case the easiest fix would be to tweak the error message. But interactive, optimizing, native compilation *does* sound like a cool and relatively cheap-to-implement feature :)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1526#changelog
http://ghc.haskell.org/trac/ghc/ticket/1530
http://ghc.haskell.org/trac/ghc/ticket/1530#1530: debugging :steps inside TH spliced code need to be bypassedFri, 13 Jul 2007 11:13:25 GMTmnislaih<p>
See test dynbrk005 for an example
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1530#changelog
http://ghc.haskell.org/trac/ghc/ticket/1532
http://ghc.haskell.org/trac/ghc/ticket/1532#1532: Implicit parameters are not available in breakpointsFri, 13 Jul 2007 11:26:55 GMTmnislaih<p>
We may want to leave this for after 6.8
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1532#changelog
http://ghc.haskell.org/trac/ghc/ticket/1534
http://ghc.haskell.org/trac/ghc/ticket/1534#1534: [Debugger] Watch on accesses of "variables"Fri, 13 Jul 2007 21:03:31 GMTiampure@…<p>
I would like to put a "watch" on certain parts of records. With such a watch in place, when writing to such a part of a record (e.g. foo{bar = 2} a new break point would be activated and the current line number would be shown somewhere. I believe the "watch" terminology is used in other debuggers. Often such a breakpoint will halt in a set_foo_bar function. This obviously would be the wrong result. The result should be a chain of calls like in the output of -xc. The user should be able to quickly move through such chains (with showing line numbers, etc).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1534#changelog
http://ghc.haskell.org/trac/ghc/ticket/1544
http://ghc.haskell.org/trac/ghc/ticket/1544#1544: Derived Read instances for recursive datatypes with infix constructors are too inefficientWed, 18 Jul 2007 05:24:51 GMTjcpetruzza@…<p>
Consider this definition:
</p>
<pre class="wiki">data Exp = C | Exp :+: Exp | Exp :-: Exp deriving ( Read, Show )
</pre><p>
Now, try something like:
</p>
<pre class="wiki">> read "((((((((((C))))))))))" :: Exp
</pre><p>
Even this simple expression may take several seconds to parse. It gets worse if you keep adding parenthesis. And even worse if you add more infix constructors....
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1544#changelog
http://ghc.haskell.org/trac/ghc/ticket/1572
http://ghc.haskell.org/trac/ghc/ticket/1572#1572: Make it easy to find documentation for GHC and installed packagesWed, 01 Aug 2007 09:58:10 GMTsimonpj<p>
<tt>ghc-pkg</tt> builds a package database that helps GHC find all installed packages. But it'd be a great improment if the same step also helped the <strong>user</strong> find the Haddock documentation for all installed packages.
</p>
<p>
Corresponding to GHC's package database would be an HTML page that is a single point of entry for the user to find documentation about installed packages. Preferably together with a consolidated index. (And maybe <tt>ghc --help</tt> should give the local URL of this documentation root.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1572#changelog
http://ghc.haskell.org/trac/ghc/ticket/1574
http://ghc.haskell.org/trac/ghc/ticket/1574#1574: Broken link testingWed, 01 Aug 2007 22:22:46 GMTiampure@…<p>
On <a href="http://www.haskell.org/ghc/dist/current/docs/">http://www.haskell.org/ghc/dist/current/docs/</a> the link ../users_guide/index.html is broken.
</p>
<p>
Suggested fix to make sure this never happens again: let a broken link analyser be part of the build bots.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1574#changelog
http://ghc.haskell.org/trac/ghc/ticket/1600
http://ghc.haskell.org/trac/ghc/ticket/1600#1600: Optimisation: CPR the results of IOWed, 08 Aug 2007 10:28:40 GMTsimonmar<p>
GHC currently cannot unbox the result of a function in the IO monad. For example:
</p>
<pre class="wiki">facIO :: Int -> IO Int
facIO n = if n < 2 then return 1 else do n' <- facIO (n-1); return (n*n')
</pre><p>
the <tt>Int</tt> argument is unboxed fine, but not the result. It ought to be possible to do this: the CPR analysis needs to somehow look inside the unboxed pair returned by IO-monadic code.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1600#changelog
http://ghc.haskell.org/trac/ghc/ticket/1612
http://ghc.haskell.org/trac/ghc/ticket/1612#1612: GHC_PACKAGE_PATH and $topdir bugSun, 12 Aug 2007 11:06:22 GMTeivuokko<p>
In ghc-pkg $topdir is replaced according to path to package that is considered global - the last on in GHC_PACKAGE_PATH (if it doesn't contain trailing ';')
</p>
<p>
Following shows how (head, 1.1.7) Cabal's haddock-command gets broken.
</p>
<pre class="wiki">C:\Users\eivuokko>copy con temp.conf
[]
^Z
1 file(s) copied.
C:\Users\eivuokko>set GHC_PACKAGE_PATH=c:\tools\ghc\ghc-6.6.1\package.conf;c:\Us
ers\eivuokko\temp.conf
C:\Users\eivuokko>ghc-pkg field base haddock-interfaces
haddock-interfaces: c:\Users\eivuokko\html\libraries\base\base.haddock
C:\Users\eivuokko>set GHC_PACKAGE_PATH=
C:\Users\eivuokko>ghc-pkg field base haddock-interfaces
haddock-interfaces: C:/tools/ghc/ghc-6.6.1\html\libraries\base\base.haddock
C:\Users\eivuokko>
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1612#changelog
http://ghc.haskell.org/trac/ghc/ticket/1614
http://ghc.haskell.org/trac/ghc/ticket/1614#1614: Type checker does not use functional dependency to avoid ambiguityTue, 14 Aug 2007 21:59:39 GMTguest<p>
Compiling the following module gives an error
</p>
<pre class="wiki">module X where
class C a | -> a
instance C Int
unC :: (C a) => a -> Int
unC i = undefined
test :: Int
test = unC undefined
</pre><p>
Error message:
</p>
<pre class="wiki">X.hs:13:7:
Ambiguous type variable `a' in the constraint:
`C a' arising from a use of `unC' at X.hs:13:7-19
Probable fix: add a type signature that fixes these type variable(s)
</pre><p>
But that is just plain wrong. The functional dependency in the definition of C forces a to be Int. No other type is possible. So what's ambiguous about that?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1614#changelog
http://ghc.haskell.org/trac/ghc/ticket/1620
http://ghc.haskell.org/trac/ghc/ticket/1620#1620: ModBreaks.modBreaks_array not initialisedSun, 19 Aug 2007 19:09:55 GMTguest<p>
Somehow the following came up:
<strong>* Exception: ModBreaks.modBreaks_array not initialised
</strong></p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1620#changelog
http://ghc.haskell.org/trac/ghc/ticket/1628
http://ghc.haskell.org/trac/ghc/ticket/1628#1628: warning(s) for using stolen syntax that's not currently enabledWed, 22 Aug 2007 16:02:38 GMTIsaac Dupree<p>
Turning on <tt>-fglasgow-exts</tt> makes <tt>f x = id$x</tt> break. I propose having a flag to warn about things like this, enabled by <tt>-Wall</tt>. To be precise, "stolen syntax" is syntax that means something valid in (usually) Haskell98 and something different with some extension enabled. If there are syntax-stealing extensions implemented by other non-GHC compilers, we may want to warn about those too. (This includes all keywords, possibly other words like "forall", "exists", "family", unicode symbols for <tt>-></tt> and others...)
</p>
<p>
If anyone actually agrees on or implements a (optional) change to unary-minus, this would subsume the warning aspects of <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1318" title="feature request: add warning for prefix negate operator and flag to replace it with ... (new)">#1318</a>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1628#changelog
http://ghc.haskell.org/trac/ghc/ticket/1631
http://ghc.haskell.org/trac/ghc/ticket/1631#1631: Make the External Package Table contain ModDetails not ModIfaceThu, 23 Aug 2007 10:24:55 GMTsimonpj<p>
Currently the <tt>External Package Table</tt> contains <tt>ModIfaces</tt>. But that makes it hard to answer the question "which instances were introduced by module Foo" in the GHC API. See Kenny Lu's problem <a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-users/2007-August/013027.html"><span class="icon"></span>http://www.haskell.org/pipermail/glasgow-haskell-users/2007-August/013027.html</a>
</p>
<p>
Furthermore the <tt>ModIfaces</tt> in the EPS are cut-down ones, with decls etc trimmed off becuase they are in the type envts.
</p>
<p>
Since <tt>loadInterface</tt> does typechecking etc, it'd make sense for it to return a <tt>ModDetails</tt> instead and for that <tt>ModDetails</tt> to be stored in the EPS. This would also tidy up the oddity that a <tt>ModIface</tt> contains redundant fields for fixity envt and deprecaction envt (they would move to <tt>ModDetails</tt>).
</p>
<p>
Then it'd also make sense for the GHC API to use <tt>ModDetails</tt> instead of <tt>ModInfo</tt>.
</p>
<p>
This change isn't truly hard, but it needs care.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1631#changelog