GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?status=!closed&priority=low&desc=1&order=type
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/query?status=!closed&priority=low&desc=1&order=type
Trac 1.0.1
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/3462
http://ghc.haskell.org/trac/ghc/ticket/3462#3462: New codegen: allocate large objects using allocateLocal()Tue, 25 Aug 2009 08:48:42 GMTsimonmar<p>
See <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3424" title="bug: Corrupt executable when compiling large do block for List monad (closed: fixed)">#3424</a>.
</p>
<p>
In the new code generator, we should allocate large objects (larger than F * block size, for some suitable fraction F) using the RTS <tt>allocateLocal()</tt> API rather than from the nursery. It works to allocate them from the nursery -- this is what GHC 6.12 does after the fix in <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3424" title="bug: Corrupt executable when compiling large do block for List monad (closed: fixed)">#3424</a> -- but then they will not be treated as large objects and will be copied during GC. Also, the allocation is likely to fail, requiring a trip through the RTS to put a large enough block in the nursery to satisfy the allocation.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3462#changelog
http://ghc.haskell.org/trac/ghc/ticket/3559
http://ghc.haskell.org/trac/ghc/ticket/3559#3559: split ghci modules off into their own packageSat, 03 Oct 2009 00:46:47 GMTigloo<p>
ghci code should be split into bits that are always compiled (and always work), and modules that are in a separate <tt>ghci</tt> package. The current situation means that clients of the GHC API cannot specify whether or not they need the ghci modules (or other code inside <tt>GHCI</tt> ifdefs), and means that clients may accidentally end up using ghci-only interfaces without realising it. This is not just hypothetical: haddock has grown a dependency on ghci code: <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3558" title="task: Make haddock compilable without ghci being enabled (closed: fixed)">#3558</a>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3559#changelog
http://ghc.haskell.org/trac/ghc/ticket/3712
http://ghc.haskell.org/trac/ghc/ticket/3712#3712: Implement -dynamic-lib optionWed, 02 Dec 2009 11:20:48 GMTsimonmar<p>
The proposal is to add a new option <tt>-dynamic-lib</tt>, to be used when building a shared library. It would be both a compile-time and a link-time option, and could be used with <tt>--make</tt> to build a complete shared library in one go. It would avoid the pitfalls caused by there being combinations of <tt>-dynamic</tt> and <tt>-fPIC</tt> don't do what the user expects.
</p>
<p>
Specifically, <tt>-dynanmic-lib</tt> would imply <tt>-dyanamic</tt>, <tt>-fPIC</tt> where necessary, and <tt>-shared</tt> when linking.
</p>
<p>
See <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3705" title="bug: -fPIC without -dynamic silently ignored (closed: wontfix)">#3705</a> for more discussion.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3712#changelog
http://ghc.haskell.org/trac/ghc/ticket/3713
http://ghc.haskell.org/trac/ghc/ticket/3713#3713: Track -dynamic/-fPIC to avoid obscure linker errorsWed, 02 Dec 2009 11:25:19 GMTsimonmar<p>
Using the wrong combination of <tt>-dynamic</tt> and/or <tt>-fPIC</tt> can lead to obscure linker errors, see e.g. <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3705" title="bug: -fPIC without -dynamic silently ignored (closed: wontfix)">#3705</a>. We should track whether an object file was compiled with <tt>-dynamic</tt> and <tt>-fPIC</tt> so that we can give better error messages before running the linker.
</p>
<p>
<strong>See also</strong>
</p><div><dl class="wiki compact"><dt><a class="new" href="/trac/ghc/ticket/3712" title="Implement -dynamic-lib option">#3712</a></dt><dd>Implement -dynamic-lib option</dd></dl></div><p>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3713#changelog
http://ghc.haskell.org/trac/ghc/ticket/3755
http://ghc.haskell.org/trac/ghc/ticket/3755#3755: Improve join point inliningTue, 15 Dec 2009 10:57:00 GMTsimonpj<p>
This ticket relates to the paper "Optimising generics is easy" <a class="ext-link" href="http://www.dreixel.net/research/pdf/ogie.pdf"><span class="icon"></span>http://www.dreixel.net/research/pdf/ogie.pdf</a>. Jose writes (about a case where inlining doesn't work well):
</p>
<blockquote>
<p>
I put a minimal source code for this test and resulting Core
(with GHC 6.13.20091115) in <a class="ext-link" href="https://subversion.cs.uu.nl/repos/staff.jpm.public/Inline/"><span class="icon"></span>https://subversion.cs.uu.nl/repos/staff.jpm.public/Inline/</a>.
<tt>UpdateInt</tt> behaves great: in <tt>UpdateInt.core.O1.hs</tt>, there are no traces of
generic representations in testOne, testTwo, testThree and testFour.
</p>
</blockquote>
<blockquote>
<p>
<tt>UpdateString</tt>, however, does not behave so well. In <tt>UpdateString.core.O1.hs</tt>,
<tt>Test.testLogic_updateString</tt> still has loads of generic representations.
</p>
</blockquote>
<p>
It's easy to see what is happening. Compile <tt>UpdateString</tt> (which I've attached to this ticket) with <tt>-ddump-simpl</tt>, and look at the core. You see stuff like
</p>
<pre class="wiki">Rec { $j1_rx32 = \x. <big nested case expression>
; f = \y. ....($j1_rx32 <big constructor expression>)
---($j1_rx32 <big constructor expression)....
}
</pre><p>
So here the <tt>$j</tt> (which is a "join point") isn't inlined because it's big, although if it <em>were</em> inlined there would be much goodness because the case expressions would cancel with the explicit constructors.
</p>
<p>
Why did this happen despite lots of INLINE pragmas? I have not followed all the details, but I'm guessing that if we have, say
</p>
<pre class="wiki"> {-# INLINE from #-}
from = \x. case x of from_alts
{-# INLINE to #-}
to = \x. case x of to_alts
</pre><p>
and we try to optimize this call:
</p>
<pre class="wiki">from (mapT f (to x))
</pre><p>
then after inlining <tt>from</tt>, <tt>mapT</tt>, and <tt>to</tt> we'll get
</p>
<pre class="wiki">case (case (case x of to_alts) of map_alts) of from_alts
</pre><p>
And now the case-of-case transform happens, which creates the join points to avoid duplicating map_alts, from_alts into every branch of to_alts. You may say that we've already said that it's ok to duplicate from (and hence from_alts) but we duplicated it once when we inlined it, and then we forget the origin of the code. And indeed, in the worse case you could get a quadratic blow up; and there are only two functions involved. So I'm not unhappy with that.
</p>
<p>
However, it does make me wonder whether we could not do a better job on the above Rec {..}. Two thoughts occur.
</p>
<ol><li>We could beef up <tt>SpecConstr</tt>. It doesn't fire at the moment for some reason, even with -O2
</li></ol><ol start="2"><li>If we have
<pre class="wiki">f = \x. case x of { C1 x11..x1n -> e1; ... Ck xk1 ... xkm -> ek }
</pre>maybe we should worker-wrapper it to
<pre class="wiki">f1 x1 .. x1n = e1
...
fn xk1 .. xkm = en
f = \x of pi -> fi xi
</pre>and now inline f. The net effect is very similar to the way join points work right now, but it would make it multi-level. In fact, doing this might simplify and generalise the way that join points are currently done, where (rather arbitrarily) we duplicate the outer layer of a single case.
</li></ol><p>
Simon
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3755#changelog
http://ghc.haskell.org/trac/ghc/ticket/3946
http://ghc.haskell.org/trac/ghc/ticket/3946#3946: Better diagnostic when entering a GC'd CAFMon, 29 Mar 2010 10:07:42 GMTsimonmar<p>
Currently a GC'd CAF contains a dangling pointer, so entering it will result in a segfault or some other random failure. It would be better to give a useful diagnostic in this case (see <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3900" title="merge: CAFs used after GC with shared libs (closed: fixed)">#3900</a>), not only to detect when <tt>keepCAFs</tt> is needed, but also to help find bugs in the code generator's SRT table generation and GC bugs.
</p>
<p>
Here is one way it could be done. We use the static link field of a static closure to indicate whether the closure is live or not:
</p>
<ul><li>link field is non-zero if and only if the closure was reachable at the last GC, otherwise it is zero
</li></ul><p>
if an <tt>IND_STATIC</tt> closure has a zero link field, then we know for sure that the closure pointed to by the <tt>IND_STATIC</tt> is invalid and entering the <tt>IND_STATIC</tt> should give a helpful error message.
</p>
<p>
To implement this:
</p>
<ul><li>on entering a CAF, set the link field to 1.
</li><li>at the beginning of (major) GC, set all the link fields for static closures that were reachable during the last major GC to zero
</li><li>during GC, link fields for reachable static closures get set to non-zero as they are linked onto first the static_objects list and then the scavenged_static_objects list.
</li></ul><p>
One problem is that this scheme means traversing and writing to all the static closures at the beginning of GC, when some of them may be dead, and many will not be in the cache. The current way of doing this at the end of GC is better from a cache perspective. To refine the above approach, we could do the extra zeroing phase at the beginning of GC for <tt>IND_STATIC</tt> closures only, and the others would get the current treatment.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3946#changelog
http://ghc.haskell.org/trac/ghc/ticket/4281
http://ghc.haskell.org/trac/ghc/ticket/4281#4281: Make impredicativity work properlyWed, 01 Sep 2010 11:44:08 GMTsimonpj<p>
This ticket is a placeholder for work on impredicativity. In fact, with the new typechecker we have most of the story for impredicativity in place, in the style of QML. Still missing are:
</p>
<ul><li>Rigid type signatures
</li><li>Notation for type application
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/4281#changelog
http://ghc.haskell.org/trac/ghc/ticket/5140
http://ghc.haskell.org/trac/ghc/ticket/5140#5140: Fix LLVM backend for PowerPCTue, 19 Apr 2011 22:15:32 GMTerikd<p>
LLVM backend does not work for PowerPC.
</p>
<p>
From bug <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/5131" title="bug: linux-powerpc : panic in stage1 compiler (closed: fixed)">#5131</a> davidt says the order of business is:
</p>
<pre class="wiki"> a) Get unregistered working.
b) Get registered without TABLES_NEXT_TO_CODE.
c) Get TABLES_NEXT_TO_CODE working.
d) Ask David where to go from there.
</pre><p>
Actually there is now a guide of sorts <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/GHC_LLVMPorting">here</a>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5140#changelog
http://ghc.haskell.org/trac/ghc/ticket/5158
http://ghc.haskell.org/trac/ghc/ticket/5158#5158: Update .git-ignore in all the reposWed, 27 Apr 2011 14:34:51 GMTigloo<p>
Go through all the repos, making sure .git-ignore is up-to-date.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5158#changelog
http://ghc.haskell.org/trac/ghc/ticket/8313
http://ghc.haskell.org/trac/ghc/ticket/8313#8313: Poor performance of higher-order functions with unboxingTue, 17 Sep 2013 01:39:39 GMTdolio<p>
I was testing out some code to see how GHC handled some unboxed higher-order functions, and was suprised by the results I found. Here is some sample code:
</p>
<pre class="wiki">{-# LANGUAGE BangPatterns #-}
{-# LANGUAGE LambdaCase #-}
{-# LANGUAGE MagicHash #-}
import GHC.Exts
import System.Environment
rel# :: Int# -> Int# -> Int# -> Bool
rel# i# j# k# = (i# +# j# +# k#) ># 100000000#
rel :: Int -> Int -> Int -> Bool
rel (I# i#) (I# j#) (I# k#) = rel# i# j# k#
manual :: (Int# -> Int# -> Int# -> Bool) -> (Int, Int, Int)
manual r# = go 0# 0# 0#
where
go i# j# k# | r# i# j# k# = (I# i#, I# j#, I# k#)
| otherwise = go j# k# (i# +# 1#)
{-# NOINLINE manual #-}
auto :: (Int -> Int -> Int -> Bool) -> (Int, Int, Int)
auto r = go 0 0 0
where
go !i !j !k | r i j k = (i, j, k)
| otherwise = go j k (i+1)
{-# NOINLINE auto #-}
main = getArgs >>= \case
"manual" : _ -> print $ manual rel# -- This case is significantly slower.
"auto" : _ -> print $ auto rel -- Why?
</pre><p>
A loop that has to box its loop parameters to call a predicate turns out to be significantly faster than one that uses a predicate that takes unboxed values directly.
</p>
<p>
The answer turns out to be (I believe) in ghc/utils/genapply/GenApply.hs. applyTypes has an entry [P,P,P], but only [N]. This means that the manual loop has to use a slower calling convention than the boxed loop.
</p>
<p>
I'm not sure whether this should be 'fixed,' as my encounter with it was experimental in nature, and I don't have a real use case. The comment on applyTypes says its cases cover 99% of uses, and mine is not a real use. This ticket may serve as documentation at least, though.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8313#changelog
http://ghc.haskell.org/trac/ghc/ticket/8315
http://ghc.haskell.org/trac/ghc/ticket/8315#8315: Improve specialized Hoopl moduleTue, 17 Sep 2013 09:20:53 GMTjstolarek<p>
GHC uses Hoopl to perform some of the Cmm-to-Cmm optimization passes, but instead of relying directly on Hoopl library GHC uses its own specialized module (see <a href="/trac/ghc/browser/ghc/compiler/cmm/Hoopl/Dataflow.hs">compiler/cmm/Hoopl/Dataflow.hs</a>). Interface of that module, as well as its internal implementation can be improved. Right now interface places responsibility of maintaining some of the invariants on user. It also ignores differences between forward and backward analysis. <a class="ext-link" href="http://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup"><span class="icon"></span>This wiki page</a> gives full detail about proposed design changes.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8315#changelog
http://ghc.haskell.org/trac/ghc/ticket/8723
http://ghc.haskell.org/trac/ghc/ticket/8723#8723: sdist should not have to build everythingSat, 01 Feb 2014 00:11:34 GMTnomeata<p>
It would be nice if instead of
</p>
<pre class="wiki">$ perl boot
$ ./configure
$ make
$ make sdist
</pre><p>
it would suffice to run
</p>
<pre class="wiki">$ perl boot
$ ./configure
$ make sdist
</pre><p>
and if that would not build more than necessary to generate the tarballs.
</p>
<p>
It would save time on the GHC-HEAD-Debian-Package-autobuilder that I am currently working on.
</p>
<p>
I might look into this bug eventually, but if someone else feels like doing it: Even better. (Difficulty estimated conservatively; might well be less than an hour, besides maybe waiting for test runs to finish :-))
</p>
<p>
Remember to update <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/MakingReleases">MakingReleases</a> and <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/Building/StandardTargets">Building/StandardTargets</a> if this is implemented.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8723#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/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/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 <a class="missing wiki">SysDeps?</a>.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 <a class="missing wiki">SysDeps?</a>.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/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/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/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/1768
http://ghc.haskell.org/trac/ghc/ticket/1768#1768: More flexible type signatures for data constructorsWed, 10 Oct 2007 09:29:29 GMTsimonpj<p>
See <a class="ext-link" href="http://article.gmane.org/gmane.comp.lang.haskell.cafe/29409"><span class="icon"></span>http://article.gmane.org/gmane.comp.lang.haskell.cafe/29409</a>, and the rest of the thread. The idea is to allow data constructor declarations to have things like this:
</p>
<pre class="wiki">type Foo = Int -> Bool -> T
data T where
C :: Foo
</pre><p>
This is a silly example, but the idea is not to require the arrows to be all visible at top level, and to allow the result type to be something other than visibly <tt>T</tt> itself.
</p>
<p>
I'm recording this as a feature request, since it came up on Haskell Cafe, but I'm not sure that I like it. The type signatures in data type declarations are pretty special: notably, they allow record syntax, and support strictness annotations.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1768#changelog
http://ghc.haskell.org/trac/ghc/ticket/2204
http://ghc.haskell.org/trac/ghc/ticket/2204#2204: Improve 'patterns not matched' warningsTue, 08 Apr 2008 17:17:45 GMTDeewiant<p>
Compiling the following with <tt>-fwarn-incomplete-patterns</tt>:
</p>
<pre class="wiki">module Asdf where
f :: String -> Int
f "0" = 0
g :: Int -> Int
g 0 = 0
</pre><p>
Yields:
</p>
<pre class="wiki">asdf.hs:4:0:
Warning: Pattern match(es) are non-exhaustive
In the definition of `f':
Patterns not matched:
[]
(GHC.Base.C# #x) : _ with #x `notElem` ['0']
(GHC.Base.C# '0') : (_ : _)
asdf.hs:7:0:
Warning: Pattern match(es) are non-exhaustive
In the definition of `g':
Patterns not matched: GHC.Base.I# #x with #x `notElem` [0#]
</pre><p>
Losing the 'GHC.Base' stuff along with the various octothorpes would make the error messages a lot nicer. Ideally it'd be something like <tt>Patterns not matched: x where x </tt>notElem<tt> [0]</tt> for the second case, for instance.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2204#changelog
http://ghc.haskell.org/trac/ghc/ticket/2614
http://ghc.haskell.org/trac/ghc/ticket/2614#2614: Enumeration of values for `Sys.Info.os`, `Sys.Info.arch`Sat, 20 Sep 2008 08:39:58 GMTjsnx<p>
It is desirable to have an enumeration of values that might end up in <tt>Sys.Info.os</tt> and <tt>Sys.Info.arch</tt>. Only after much reading of Cabal files and such have I learnt that the former includes (at least) <tt>linux</tt>, <tt>darwin</tt>, <tt>windows</tt> and <tt>freebsd</tt>. (And not, for example, <tt>win32</tt>.)
</p>
<p>
This is only a minor annoyance and I will likely never need to bother with it again -- though I guess I'm still not sure what Solaris is called -- probably <tt>solaris</tt> -- I've got the pattern now, but it would have been much better to see a list.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2614#changelog
http://ghc.haskell.org/trac/ghc/ticket/2708
http://ghc.haskell.org/trac/ghc/ticket/2708#2708: Error message should suggest UnboxedTuples language extensionSat, 18 Oct 2008 22:51:12 GMTtim<p>
If I compile this code:
</p>
<pre class="wiki">module Foo where
import GHC.Integer
foo x y =
case x `quotRemInteger` y of
(# y, z #) -> 42
</pre><p>
I get:
</p>
<pre class="wiki">foo.hs:7:5: Parse error in pattern
</pre><p>
It would be better if the error message suggested using <tt>-XUnboxedTuples</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2708#changelog
http://ghc.haskell.org/trac/ghc/ticket/2896
http://ghc.haskell.org/trac/ghc/ticket/2896#2896: Warning suggestion: argument not necessarily a binary operatorWed, 24 Dec 2008 07:12:32 GMTporges<p>
As an example:
</p>
<pre class="wiki">let fn (+) = 1; fn x = 2 in fn 1
</pre><p>
The suggested warning is that: if an argument to a function consists entirely of characters which are symbols (all isSymbol), and the type of that argument isn't (a -> b -> c), then produce a warning.
</p>
<p>
Suggested wording is something along the lines of "Warning: the argument '(+)' isn't necessarily a binary operator, although it looks like one. This may be confusing to readers of your code."
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2896#changelog
http://ghc.haskell.org/trac/ghc/ticket/3052
http://ghc.haskell.org/trac/ghc/ticket/3052#3052: ghc FFI doesn't support thiscallFri, 27 Feb 2009 11:59:35 GMTaugustss<p>
The ghc FFI does not support the "thiscall" calling convention.
This is the calling convention used by Microsoft C++ for calling methods.
It's like the stdcall calling convention, except that the "this" pointer is passed in ECX.
</p>
<p>
Without this calling convention it's impossible to interact with (Msft) C++ objects.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3052#changelog
http://ghc.haskell.org/trac/ghc/ticket/3372
http://ghc.haskell.org/trac/ghc/ticket/3372#3372: Allow for multiple linker instancesTue, 14 Jul 2009 22:25:01 GMTjcpetruzza<p>
Right now there is only one RTS linker with a single symbol table.This means, for example, that one cannot have multiple instances of the GHC interpreter in the same process running simultaneously.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3372#changelog
http://ghc.haskell.org/trac/ghc/ticket/3373
http://ghc.haskell.org/trac/ghc/ticket/3373#3373: GHC API is not thread safeTue, 14 Jul 2009 22:31:26 GMTjcpetruzza<p>
There are some items of global state (the <tt>NameCache</tt> and the <tt>PackageInterfaceTable</tt>) that should be protected. One can workaround this by using a mutex and only invoking GHC API operations in one thread at a time.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3373#changelog
http://ghc.haskell.org/trac/ghc/ticket/3464
http://ghc.haskell.org/trac/ghc/ticket/3464#3464: Find import declaration importing a certain functionWed, 26 Aug 2009 11:40:38 GMTfasta<p>
Given the command
</p>
<pre class="wiki">:find foo
</pre><p>
, find all import declaration that import this symbol.
</p>
<p>
Example:
</p>
<pre class="wiki">> *ModA *ModB *ModC are loaded.
</pre><p>
Suppose the modules all export Data.List.
</p>
<p>
So,
given
</p>
<pre class="wiki">module ModX(module Data.List) where import Data.List
</pre><p>
with X \in {A,B,C}
</p>
<p>
Now, when one currently does :i for a function in Data.List, one gets back that it is defined in Data.List, but that's not the information the user is interested in. The user wants to know which _modules_ define a certain symbol, so in this case it should say that modules ModA, ModB and ModC brought that symbol into scope.
</p>
<p>
The user-interface could also simply be :i as it is now, but with one extra line saying where it was imported.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3464#changelog
http://ghc.haskell.org/trac/ghc/ticket/3483
http://ghc.haskell.org/trac/ghc/ticket/3483#3483: Some mechanism for eliminating "absurd" patternsThu, 03 Sep 2009 01:09:00 GMTryani<p>
This is to help with type-level programming and doing dependent-like programming in Haskell.
</p>
<pre class="wiki">data TEq :: * -> * -> * where
TEq :: TEq a a
-- This declaration fails to compile because bringing (Int ~ Bool)
-- into scope on the RHS is unsound.
broken :: TEq Int Bool -> Int
broken TEq = 1
-- Proposal:
-- "!" replaces "=" in function declaration to say "this pattern is absurd"
proposal :: TEq Int Bool -> r
proposal TEq !
-- If, for some reason the pattern match succeeds,
-- (basically, someone broke type safety with unsafeCoerce)
-- the result could be something like calling:
-- error "absurd pattern at FILE:LINE"
</pre><p>
I'm not sure that "!" works with Haskell's syntax, but it does call attention to the pattern.
</p>
<p>
The idea is that anywhere that putting "= some_rhs" would cause the compiler to fail because it can prove that the type environment is unsound in some fashion, you could use "!" to give a valid function definition.
</p>
<p>
The same extension would be used for case statements, of course.
</p>
<p>
See also <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/2006" title="bug: unreachable GADT pattern clauses show up as warnings with -Wall (closed: fixed)">#2006</a>, which is related in spirit if not in implementation.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3483#changelog
http://ghc.haskell.org/trac/ghc/ticket/3547
http://ghc.haskell.org/trac/ghc/ticket/3547#3547: Improve granularity of UndecidableInstancesMon, 28 Sep 2009 12:00:29 GMTksf<p>
Currently, as a LANGUAGE pragma, <a class="missing wiki">UndecidableInstances?</a> can only be set once per file: Assuming that there are enough occasions where one would only need to enable it for one or two instances in a bigger source and considering that the warnings emitted if <a class="missing wiki">UndecidableInstances?</a> is not set are actually useful, it makes sense to support enabling the extension only on a per-instance basis.
</p>
<p>
proposed syntax:
</p>
<pre class="wiki">{-# LANGUAGE UndecidableInstances #-}
[code]
{-# NOLANGUAGE UndecidableInstances #-}
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3547#changelog
http://ghc.haskell.org/trac/ghc/ticket/3619
http://ghc.haskell.org/trac/ghc/ticket/3619#3619: allow to set ghc search path globally (a'la CPATH)Wed, 28 Oct 2009 13:48:12 GMTtari3x<blockquote>
<p>
I'd like a mechanism for ghc similar to setting the CPATH variable for gcc. I'd like ghc to look in the given list of paths every time it compiles something, without me having to retype the flags.
</p>
</blockquote>
<blockquote>
<p>
For ghci there is .ghci, but it gets ignored when I run ghc.
</p>
</blockquote>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3619#changelog
http://ghc.haskell.org/trac/ghc/ticket/3632
http://ghc.haskell.org/trac/ghc/ticket/3632#3632: lift restrictions on records with existential fields, especially in the presence of class constraintsMon, 02 Nov 2009 21:19:40 GMTeflister<p>
the attached file demos the use of a record with an existential field with a class constraint. it shows several cases where lifting the current restrictions on accessing and updating this field would be both well-defined and useful.
</p>
<p>
here is the record definition; the dur field is existential, but constrained to be in class <a class="missing wiki">NoteDur?</a>.
</p>
<pre class="wiki">data Note = forall x . NoteDur x => Note {
midiNum :: Int -- 0-255
, vel :: Int -- 0-255
, chan :: Int -- 0-15
, measure :: Integral a => a
, beat :: Int
, subdiv :: RealFrac a => a -- % of beat
, dur :: x
}
</pre><p>
here is a walk through of places in the code where the current restrictions are unnecessary and intrusive:
</p>
<ol><li>lines 64-95 -- these functions wouldn't be necessary if record update syntax were enabled for both existential and non-existential fields. i know 6.12 introduces it for non-existentials, but i don't see why it isn't also possible for existential fields (even without a class constraint). lines 33-35 and 60 show how much nicer it is to use regular updater syntax in this case.
</li></ol><ol start="2"><li>Line 142. The same is true for existential accessors when there is a class constraint -- there's no need to restrict this situation because the accessor can have type:
<pre class="wiki">fieldName :: (SomeClass x) => Record -> x
</pre>line 142 shows a case where this would be very nice to have.
</li></ol><ol start="3"><li>line 100 + 107 -- the foralls could be implicit (maybe offer an extention that would allow them to be implicit)
</li></ol><ol start="4"><li>lines 134-136 compared to 138-139 show how additional factoring could be achieved if one were allowed to pattern match on the type of an existential with class constraints.
</li></ol><ol start="5"><li>lines 124-127 show how it would be nice to have existential classes
</li></ol><ol start="6"><li>lastly, allow curried updater functions: <tt>(rec {field = }) 5</tt> instead of <tt>(\x -> (rec {field = x})) 5</tt>
</li></ol>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3632#changelog
http://ghc.haskell.org/trac/ghc/ticket/3645
http://ghc.haskell.org/trac/ghc/ticket/3645#3645: Layout and pragmasSat, 07 Nov 2009 12:40:23 GMTigloo<p>
With this module:
</p>
<pre class="wiki">{-# LANGUAGE DeriveDataTypeable,
FlexibleContexts
#-}
module Foo where
</pre><p>
GHC 6.12 says:
</p>
<pre class="wiki"> Cannot parse LANGUAGE pragma
Expecting comma-separated list of language options,
each starting with a capital letter
E.g. {-# LANGUAGE RecordPuns, Generics #-}
</pre><p>
but this should probably be allowed. See <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3519" title="bug: ghc: panic! (the 'impossible' happened) (closed: fixed)">#3519</a>, <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3616" title="feature request: ghci crash from :l (closed: fixed)">#3616</a>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3645#changelog
http://ghc.haskell.org/trac/ghc/ticket/3699
http://ghc.haskell.org/trac/ghc/ticket/3699#3699: Wildcards in type functionsFri, 27 Nov 2009 10:01:09 GMTMartijnVanSteenbergen<p>
I would like to be able to use wildcards in type synonym family instances, so that I can write:
</p>
<pre class="wiki">type instance ErrorAlg (f :>: _) e a = ErrorAlg f e a
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3699#changelog
http://ghc.haskell.org/trac/ghc/ticket/3701
http://ghc.haskell.org/trac/ghc/ticket/3701#3701: allow existential wrapper newtypesSat, 28 Nov 2009 20:42:04 GMTduncan<p>
Consider this OO-style thing, a class Compiler, and a most general instance <a class="missing wiki">MkCompiler?</a>:
</p>
<pre class="wiki">class Compiler c where
getInstalledPackages :: c -> IO [String]
data GHC = GHC { }
data NHC = NHC { }
ghc :: GHC
ghc = GHC { }
nhc :: NHC
nhc = NHC { }
instance Compiler GHC
instance Compiler NHC
data MkCompiler where
MkCompiler :: Compiler c => c -> MkCompiler
instance Compiler MkCompiler where
getInstalledPackages (MkCompiler c) = getInstalledPackages c
compilers :: [MkCompiler]
compilers = [MkCompiler ghc, MkCompiler nhc]
</pre><p>
There's two language features we want to make this really nice:
</p>
<ol><li>Letting us call the data type <tt>Compiler</tt> rather than <tt>MkCompiler</tt>. That would mean separating the class and type namespaces.
</li><li>Letting us derive the Compiler instance for <tt>MkCompiler</tt>.
</li></ol><p>
For the latter we would want either:
</p>
<pre class="wiki">newtype MkCompiler where
MkCompiler :: Compiler c => c -> MkCompiler
deriving Compiler
</pre><p>
or
</p>
<pre class="wiki">data MkCompiler where
MkCompiler :: Compiler c => c -> MkCompiler
deriving Compiler
</pre><p>
The advantage of the first is that newtype deriving already exists as a concept so that's nice and consistent. The problem is we do not allow newtypes that use existentials. From an implementation point of view, it's clear that the representations cannot be equal because of the need to store the class dictionary. From a semantic point of view however it's not obvious that existentials with class contexts are illegitimate in newtypes. The underlying implementation would of course have to be an extra layer of boxing, so like data but with the pattern match behaviour newtype.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3701#changelog
http://ghc.haskell.org/trac/ghc/ticket/3753
http://ghc.haskell.org/trac/ghc/ticket/3753#3753: Make ghci's -l option consistent with GNU ld's -l optionTue, 15 Dec 2009 09:50:26 GMThgolden<p>
Currently, ghci accepts -l options of the format -lxyz. On Linux, this is treated as a request for libxyz.so. The GNU ld -l option is more flexible. It accepts either -lxyz or -l xyz. Also, it accepts -l:filename or -l :filename. When this form is used, the filename is not modified by prepending "lib" and appending ".so". I request that GNU ld's -l forms be accepted by ghci.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3753#changelog
http://ghc.haskell.org/trac/ghc/ticket/3786
http://ghc.haskell.org/trac/ghc/ticket/3786#3786: showing function arguments when stopped at its definitionFri, 25 Dec 2009 13:00:00 GMTphercek<p>
It would be cool if GHCi debugger could grab not only the free variables in the selected expression but, in one case, a bit more. The case is when we stop at a function definition the first time (when just entering it). In this case, the debugger should provide the bindings for the function arguments. If a function uses pattern matching or when there are multiple equations with different formal argument names then there may not be any suitable name for the for the actual argument value. Because of this, we introduce the function argument names like: _arg1, _arg2, ... _argN. Numbering starts from 1 for the first formal argument of a function.<br />
The special _argN names should be provided always, even when there is a unique name for the argument in the source code.
</p>
<p>
This request was discussed here:
<a class="ext-link" href="http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/17204"><span class="icon"></span>http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/17204</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3786#changelog
http://ghc.haskell.org/trac/ghc/ticket/3869
http://ghc.haskell.org/trac/ghc/ticket/3869#3869: RTS GC Statistics from -S should be logged via the eventlog systemMon, 08 Feb 2010 06:38:13 GMTcjs<p>
The -Sfilename option to the RTS gives useful GC statistics, but it's hard to correlate these with other events, particularly to see if GC is interrupting critical sections in mutator threads. If the same information were instead logged via the eventlog system (perhaps enabled via a "-lg" option) one could get more insight into the garbage generation and collection behaviour of one's program.
</p>
<p>
Note that it's probably not necessary also to store the information given at the end of the run with both "-s" and "-S", though it may be interesting to contemplate moving this sort of thing into the eventlog file as well.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3869#changelog
http://ghc.haskell.org/trac/ghc/ticket/3895
http://ghc.haskell.org/trac/ghc/ticket/3895#3895: "Fix" pervasive-but-unnecessary signedness in GHC.PrimMon, 22 Feb 2010 20:51:28 GMTpumpkin<p>
I'm talking about the array primitives in particular:
</p>
<pre class="wiki">writeFloatArray# :: MutableByteArray# s -> Int# -> Float# -> State# s -> State# s
</pre><p>
Conceptually, a Word# makes more sense as the index for all the array functions. I'm not even sure what the semantics are if the Int# is negative... is it checked? The three scenarios I can think of are:
</p>
<p>
Negativity is checked, and you get an exception.
Negativity is unchecked, and you get to write to memory that comes before your array.
Negativity is ignored, and the back-end treats the Int# like a Word# already.
</p>
<p>
I think the switch would be worthwhile in all of those cases, and could be hidden in higher-level APIs that still use Int for indexes with a simple int2Word#. Eventually we might even migrate to Word-based APIs at that level?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3895#changelog
http://ghc.haskell.org/trac/ghc/ticket/3977
http://ghc.haskell.org/trac/ghc/ticket/3977#3977: Support double-byte encodings (Chinese/Japanese/Korean) on WindowsSun, 11 Apr 2010 06:38:50 GMTshelarcy<p>
localeEncoding uses the console code page for text file encoding/decoding for single-byte encoding environment on Windows. But GHC.IO.Encoding.<a class="missing wiki">CodePage?</a>.Table doesn't have double-byte encodings (<a class="missing wiki">Chinese/Japanese/Korean?</a>), now. Its current state often causes problem on double-byte encoding environment.
</p>
<ul><li><a class="ext-link" href="http://hackage.haskell.org/trac/hackage/ticket/658"><span class="icon"></span>http://hackage.haskell.org/trac/hackage/ticket/658</a>
</li><li><a class="ext-link" href="http://hackage.haskell.org/trac/hackage/ticket/659"><span class="icon"></span>http://hackage.haskell.org/trac/hackage/ticket/659</a>
</li></ul><p>
I know we can solve problem by using hSetEncoding with utf8 or othere UTF-* encodings. But it's not good solution.
</p>
<p>
According to previous Windows patch, GHC.IO.Encoding.<a class="missing wiki">CodePage?</a>.Table doesn't support double-byte encodings because Windows' shared library support doesn't work.
</p>
<ul><li><a class="ext-link" href="http://www.haskell.org/pipermail/cvs-libraries/2009-September/011289.html"><span class="icon"></span>http://www.haskell.org/pipermail/cvs-libraries/2009-September/011289.html</a>
</li><li><a class="ext-link" href="http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=packages/base;a=commitdiff;h=20090913022126-9f663-2bb505cf915b18313bf41a25853d9d13d7444feb.gz"><span class="icon"></span>http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=packages/base;a=commitdiff;h=20090913022126-9f663-2bb505cf915b18313bf41a25853d9d13d7444feb.gz</a>
</li></ul><pre class="wiki">Currently we do not support double-byte encodings (Chinese/Japanese/Korean), since
including those codepages would increase the table size to 400KB. It will be
straightforward to implement them once the work on library DLLs is finished.
</pre><p>
I think Windows' shared library support works now. Because <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/3879" title="feature request: Enable shared libraries on Windows (closed: fixed)">#3879</a> is closed.
</p>
<p>
So, how about add supporting double-byte encodings (<a class="missing wiki">Chinese/Japanese/Korean?</a>) on Windows?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3977#changelog
http://ghc.haskell.org/trac/ghc/ticket/3980
http://ghc.haskell.org/trac/ghc/ticket/3980#3980: System.Posix.Signals should provide a way to set the SA_NOCLDWAIT flagSun, 11 Apr 2010 18:24:40 GMTLiskni_si<p>
Since FreeBSD and OpenBSD don't conform to POSIX.1-2001 regarding the creation of zombie processes, “installHandler sigCHLD Ignore Nothing” just isn't enough to stop zombies from piling up. They do, however, support the SA_NOCLDWAIT flag to sigaction, and an interface for it would be useful to have.
</p>
<p>
The motivation is this: <a class="ext-link" href="http://thread.gmane.org/gmane.comp.lang.haskell.xmonad/9780"><span class="icon"></span>http://thread.gmane.org/gmane.comp.lang.haskell.xmonad/9780</a>
More info: <a class="ext-link" href="http://en.wikipedia.org/wiki/SIGCHLD"><span class="icon"></span>http://en.wikipedia.org/wiki/SIGCHLD</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3980#changelog
http://ghc.haskell.org/trac/ghc/ticket/4016
http://ghc.haskell.org/trac/ghc/ticket/4016#4016: Strange display behaviour in GHCiMon, 26 Apr 2010 10:08:57 GMTsimonpj<p>
Kazu encountered another GHCi oddity. Try ":browse Prelude" in GHCi. With 6.12 we get
</p>
<pre class="wiki">data Integer
= integer-gmp:GHC.Integer.Type.S# GHC.Prim.Int#
| integer-gmp:GHC.Integer.Type.J# GHC.Prim.Int# GHC.Prim.ByteArray#
</pre><p>
Why do we get the <tt>integer-gmp:</tt> prefix? There is no ambiguity here. (GHC 6.10 didn't do this, but that's because <tt>Integer</tt> was in the <tt>base</tt> package, whereas now <tt>Integer</tt> is in <tt>integer-gmp</tt>.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4016#changelog
http://ghc.haskell.org/trac/ghc/ticket/4020
http://ghc.haskell.org/trac/ghc/ticket/4020#4020: Please consider adding support for local type synonymsTue, 27 Apr 2010 00:33:29 GMTnr<p>
I would really like to be able to put a type synonym in a where clause. I'm willing to specify <tt>LANGUAGE ScopedTypeVariables, LiberalTypeSynonyms</tt>.
</p>
<p>
For an example use case, please see line 202 of the attachment.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4020#changelog
http://ghc.haskell.org/trac/ghc/ticket/4052
http://ghc.haskell.org/trac/ghc/ticket/4052#4052: Two sided sectionsFri, 07 May 2010 12:38:27 GMTaavogt<p>
Allow sections to be functions of two arguments:
</p>
<pre class="wiki">( # c ## ) a b === a # c ## b
</pre><p>
Where the associativities of <em>#</em> and <em>##</em> are then used.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4052#changelog
http://ghc.haskell.org/trac/ghc/ticket/4096
http://ghc.haskell.org/trac/ghc/ticket/4096#4096: New primops for indexing: index*OffAddrUsing# etcTue, 25 May 2010 15:36:53 GMTsimonpj<p>
Here's an email from Roman, and response from Simon. Making a ticket so it's kept as an idea.
</p>
<p>
In package vector, primitive vectors (the ones that <tt>Data.Vector.Unboxed</tt> is built on top of) are represented as follows (<tt>ByteArray</tt> and friends are wrappers for various GHC primitives provided by package primitive):
</p>
<pre class="wiki">data Vector a = Vector Int -- offset into the ByteArray
Int -- length
ByteArray -- data
</pre><p>
This representation supports cheap slicing which is quite crucial. However, indexing into such vectors is a bit more expensive than necessary:
</p>
<pre class="wiki">index (Vector i _ arr) j = indexByteArray arr (i+j)
</pre><p>
Ultimately, this requires 2 additions to get the element's address:
</p>
<pre class="wiki"> <base address off the ByteArray> + ((i + j) * <size of element>)
</pre><p>
I'd like to always allocate pinned <tt>ByteArrays</tt> and store the starting address of the vector instead of the offset:
</p>
<pre class="wiki">data Vector a = Vector Addr
Int
ByteArray
</pre><p>
This would make indexing cheaper as it would require only one addition:
</p>
<pre class="wiki">index (Vector addr i _) = indexOffAddr addr i
</pre><p>
This is quite a big deal if indexing happens in an inner loop (some algorithms become up to 20% faster). Of course, the backend could optimise the offset-based version by performing partial redundancy elimination but it doesn't and it probably wouldn't get all interesting cases even if it did. So the second version is better.
</p>
<p>
The problem is that I can't implement it because I must touch the <tt>ByteArray</tt> after accessing the memory. This results in code like this which hides the constructor, breaking various optimisations:
</p>
<pre class="wiki"> case indexIntOffAddr# addr# i# of { n# ->
case touch# arr# realWorld# of { _ -> I# n# }}
</pre><p>
After thinking about this for a while, I came up with two possible solutions. One is to provide a "pure" version of touch#:
</p>
<pre class="wiki"> use# :: o -> o' -> o'
</pre><p>
such that use# x y = y. This would change the code above to:
</p>
<pre class="wiki"> I# (use# arr# (indexIntOffAddr# addr# i#))
</pre><p>
I don't know how to implement this, though, because use# would have to be able to return arbitrary (unboxed) types and the code generator doesn't really seem to support this.
</p>
<p>
A perhaps simpler solution is to add a new set of primitives:
</p>
<pre class="wiki"> indexIntOffAddrUsing# :: o -> Addr# -> Int# -> Int#
...
</pre><p>
These would take an additional argument which they'd touch and otherwise ignore. The code would then become:
</p>
<pre class="wiki"> I# (indexIntOffAddrUsing# arr# addr# i#)
</pre><p>
Incidentally, the <tt>index*OffAddr#</tt> primitives don't seem to be used anywhere. [Not true: there are a handful of uses of <tt>index*OffAddr#</tt> in libraries/base, mainly GHC.Base.]
</p>
<p>
Simon replies:
<tt>indexIntOffAddrUsing#</tt> seems like the way to go, I can't think of a better alternative.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4096#changelog
http://ghc.haskell.org/trac/ghc/ticket/4114
http://ghc.haskell.org/trac/ghc/ticket/4114#4114: Add a flag to remove/delete intermediate files generated by GHCWed, 02 Jun 2010 21:37:46 GMTguest<p>
See for example <a class="ext-link" href="http://stackoverflow.com/questions/1411089/how-to-stop-ghc-from-generating-intermediate-files"><span class="icon"></span>http://stackoverflow.com/questions/1411089/how-to-stop-ghc-from-generating-intermediate-files</a> or
<a class="ext-link" href="http://www.haskell.org/pipermail/xmonad/2010-May/010180.html"><span class="icon"></span>http://www.haskell.org/pipermail/xmonad/2010-May/010180.html</a> /
</p>
<p>
Currently GHC generates *.o and *.hi files for executables, possibly quite a few. They take up space, filenames, and interfere with tab-completion.
</p>
<p>
(And they may be worse than that. I occasionally see users in #xmonad who seem to have subtle compilation issues after upgrades linked to stale .hi and .o files.)
</p>
<p>
There doesn't seem to be any good way to remove the intermediates for a program like Xmonad. They can't be redirected to /dev/null, it's a potential security problem to redirect them to /tmp, and removing them manually is difficult (Xmonad could hardwire in removeFiles of 'xmonad.o' and 'xmonad.hi', but what about the arbitrary user modules in ~/.xmonad/lib? Now one needs to start working with globs or utilities like 'find'...).
</p>
<p>
Of course, GHC knows precisely what's being generated, and could easily remove them. So another flag in the line of -fforce-recompilation seems warranted; perhaps -fforce-no-intermediates?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4114#changelog
http://ghc.haskell.org/trac/ghc/ticket/4180
http://ghc.haskell.org/trac/ghc/ticket/4180#4180: do not consider associativity for unary minus for fixity resolutionThu, 08 Jul 2010 15:25:47 GMTmaeder<ol><li> currently an expression "1 + - 1" is rejected, because "1 + (-1)" looks as being bracketed to the right, whereas + and - are left associative. However, no other bracketing is possible, so "1 + - 1" is unambiguous and should not be subject to further fixity resolution.
</li></ol><ol start="2"><li> if an infix expressions starts with an unary minus, the associativity should not matter for the unary minus. Why should "- 1 ## 1" be rejected for a right- or non-assoc operator "##"? Precedence alone is sufficient to decide between "(- 1) ## 1" and "- (1 ## 1)". The latter choice is taken for a higher precedence of the infix operator and the former choice should always be taken
</li></ol><p>
for an equal or lower precedence as is done for "- 1 + 1", but without looking at associativity!
</p>
<p>
I'll attach an alternative fixity resolution in the spirit of
10.6 of <a class="ext-link" href="http://www.haskell.org/~simonmar/haskell-2010-draft-report-2/haskellch10.html"><span class="icon"></span>http://www.haskell.org/~simonmar/haskell-2010-draft-report-2/haskellch10.html</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4180#changelog
http://ghc.haskell.org/trac/ghc/ticket/4213
http://ghc.haskell.org/trac/ghc/ticket/4213#4213: LLVM: Add support for TNTC to LLVM compiler suiteFri, 23 Jul 2010 13:44:14 GMTdterei<p>
At the moment we handle TNTC in the LLVM backend in two different ways:
</p>
<p>
<a class="missing wiki">Linux/Windows?</a>: We use the GNU As subsections feature to order sections. Works very nicely. Slight hack in that we create special section names that contain comments. (Asm injection)
</p>
<p>
Mac: Mac assembler doesn't support the GNU As subsections feature, so we post-process the assembly code produced by llc.
</p>
<p>
Both these methods (especially Mac) are hacks. It would be better to extend LLVM to support the TNTC feature.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4213#changelog
http://ghc.haskell.org/trac/ghc/ticket/4222
http://ghc.haskell.org/trac/ghc/ticket/4222#4222: Template Haskell lets you reify supposedly-abstract data typesMon, 26 Jul 2010 11:02:46 GMTsimonpj<p>
Serguey Zefirov writes (<a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2010-July/079802.html"><span class="icon"></span>on Haskell cafe</a>) "Data.Map.Map and Data.Set.Set are exported abstractly, without exposing knowledge about their internal structure.
</p>
<p>
I cannot directly create my own class instances for them because of that. But I found that I can write Template Haskell code that could do that - those data types could be reified just fine."
</p>
<p>
Good point. It's not quite clear what a better design should be. Haskell controls data abstraction by whether or not the constructors of the data type are exported. But they might be exported by the module that <em>defined</em> them, but <em>not</em> to "clients" of the data type. So the data type is abstract to some importers but concrete to others.
</p>
<p>
So when should TH let you reify the representation of a data type? Maybe it should let you do so iff
</p>
<ul><li>The data constructors of the data type are in scope (somehow) at the reification site
</li></ul><p>
So, to take an example:
</p>
<pre class="wiki">module Conc( T(..), Blah(..) ) where
data T = T1 | T2 Blah
data Blah = A | B
module Abs( T, Blah ) where
import Conc
module ReifyA where
import Abs
foo = reify ''T
module ReifyC where
import Conc
foo = reify ''T
</pre><p>
So the <tt>reify</tt> in <tt>ReifyC.foo</tt> would "see" the data constructors of <tt>T</tt>, but not the one in <tt>ReifyA</tt>.
</p>
<p>
But this approach raises related questions.
</p>
<ul><li>What if some, but not all, of <tt>T</tt>'s data constructors are in scope?
</li></ul><ul><li>What if the data constructors are all in scope, but some mention a type that is not in scope? For example, suppose type <tt>Blah</tt> is not in scope, but you reify <tt>T</tt>?
</li></ul><ul><li>At the moment, when you reify a data type you get its <tt>Dec</tt>. But if <tt>T</tt> is abstract, what <tt>Dec</tt> can we give it? Just giving it an empty constructor list seems wrong; after all, it might really <em>be</em> a zero-constructor data type. I suspect we may want a richer data type for <tt>Info</tt> (ie what <tt>reify</tt> returns).
</li></ul><p>
All these require design thinking. Does anyone want to lead that debate? Otherwise things will probably stay as they are.
</p>
<p>
I've labelled this as a feature request, although it is a kind of bug, because of this design component.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4222#changelog
http://ghc.haskell.org/trac/ghc/ticket/4316
http://ghc.haskell.org/trac/ghc/ticket/4316#4316: Interactive "do" notation in GHCiWed, 15 Sep 2010 04:57:53 GMTmitar<p>
Enable GHCi to run commands under StateT monad based on IO or maybe even any other monad based on IO. So that you could for example exec a state and "fall" into this monad.
</p>
<p>
This could be generalized by supporting interactive "do" notation. Currently doing something like:
</p>
<pre class="wiki">(flip execStateT) state $ do
</pre><p>
raises "Empty 'do' construct" warning, but GHCi could go into interactive mode where it would be possible to write one command after another and it would execute them.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4316#changelog
http://ghc.haskell.org/trac/ghc/ticket/4329
http://ghc.haskell.org/trac/ghc/ticket/4329#4329: GHC.Conc modifyTVar primitiveTue, 21 Sep 2010 20:18:14 GMTdmbarbour<p>
I would like modifyTVar as a 'write-only' primitive supported by GHC's STM.
</p>
<p>
The semantic definition is:
</p>
<blockquote class="citation">
<p>
modifyTVar :: TVar a -> (a -> a) -> STM ()
modifyTVar v f = readTVar v >>= writeTVar v . f
</p>
</blockquote>
<p>
However, explicitly reading then writing the TVar introduces unnecessary interference between transactions. The value held by the TVar does not affect the behavior of the transaction. modifyTVar should not interfere with other transactions that only writeTVar or modifyTVar.
</p>
<p>
Even if a non-interfering implementation isn't feasible due to the underlying implementation of GHC's STM, providing the function would provide a point for a transparent upgrade in the future.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4329#changelog
http://ghc.haskell.org/trac/ghc/ticket/4340
http://ghc.haskell.org/trac/ghc/ticket/4340#4340: Add alignment to hsc2hs templateSat, 25 Sep 2010 22:19:42 GMTmitar<p>
I think <a class="ext-link" href="http://www.haskell.org/haskellwiki/FFICookBook#Working_with_structs"><span class="icon"></span>commonly used</a>:
</p>
<pre class="wiki">#let alignment t = "%lu", (unsigned long)offsetof(struct {char x__; t (y__); }, y__)
</pre><p>
should be added to official hsc2hs template. What are cons to that?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4340#changelog
http://ghc.haskell.org/trac/ghc/ticket/4426
http://ghc.haskell.org/trac/ghc/ticket/4426#4426: Simplify the rules for implicit quantificationFri, 22 Oct 2010 08:19:18 GMTsimonpj<p>
This thread <a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-users/2010-October/019360.html"><span class="icon"></span>http://www.haskell.org/pipermail/glasgow-haskell-users/2010-October/019360.html</a>
convinced me that GHC's rules for implicit quantification are unnecessarily complicated.
</p>
<hr />
<h2 id="Thecurrentspec">The current spec</h2>
<p>
The current spec seems to be this:
</p>
<ul><li>Define an "implicit quantification point" to be (a) the type in a type signature <tt>f :: type</tt> if <tt>type</tt> does not start with <tt>forall</tt>; or (b) a type of form <tt>(context => type)</tt>, that is not immediately enclosed by an explicit <tt>forall</tt>
</li></ul><ul><li>At each implicit quantification point 'ty', working outside in, GHC finds all the type variables a,b,c in 'ty' that are not already in scope, and transforms 'ty' to (forall a,b,c. ty).
</li></ul><p>
Note that
</p>
<ul><li>The argument of a constructor is not an implicit quantification point, so that
<pre class="wiki">data Foo = MkFoo (a -> a)
</pre>is an error, and does not mean
<pre class="wiki">data Foo = MkFoo (forall a. a->a)
</pre></li></ul><ul><li>Implicit quantification points may be nested but the inner ones are effectively no-ops. Example
<pre class="wiki">f :: Int -> (Eq a => a -> a) -> Int
</pre>There are two quantification points: the whole type, and the <tt>(Eq a => ...)</tt>. But when the outer quantification point wraps forall a around it, the inner quantification point has no free variables to quantify. So we get
<pre class="wiki">f :: forall a. Int -> (Eq a => a -> a) -> Int
</pre></li></ul><hr />
<h2 id="Thenewproposal">The new proposal</h2>
<p>
The proposed new rule is this:
</p>
<ul><li>Implicit quantification applies only to an entire user type signature that does not start with <tt>forall</tt>.
</li><li>For such signatures, find all the type variables a,b,c in the signature that are not already in scope, and prefix the signature with <tt>forall a,b,c.</tt>
</li></ul><p>
I believe that the only observable changes in behaviour would be
</p>
<ul><li>In a data type declaration
<pre class="wiki">data Foo = MkFoo (Eq a => a -> a)
</pre>you'd get an error "a is not in scope", just as you would with
<pre class="wiki">data Foo = MkFoo (a->a)
</pre>To me this seems more consistent behavour.
</li></ul><ul><li>Inside an <em>explicit</em> <tt>forall</tt> you would get no <em>implicit</em> <tt>foralls</tt>:
<pre class="wiki">f :: forall a. (Eq b => b->b) -> a -> a
</pre>would yield "b is not in scope", whereas at present it behaves like
<pre class="wiki">f :: forall a. (forall b. Eq b => b->b) -> a -> a
</pre></li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/4426#changelog
http://ghc.haskell.org/trac/ghc/ticket/4429
http://ghc.haskell.org/trac/ghc/ticket/4429#4429: Ability to specify the namespace in mkNameSat, 23 Oct 2010 03:49:04 GMTreinerp<p>
Given
</p>
<pre class="wiki">data Foo
data Bar = Foo
</pre><p>
If we do <tt>reify (mkName "Foo")</tt> then we get the information about "<tt>Foo</tt> the type", and not about "<tt>Foo</tt> the constructor".
</p>
<p>
(This is problematic, say, for a quasiquoter
</p>
<pre class="wiki">[qq| ... Foo ... |]
</pre><p>
because the quasiquoter is forced to use <tt>mkName "Foo"</tt> as the <tt>Name</tt> for reify -- the forms <tt>'Foo</tt> and <tt>''Foo</tt> are unavailable to it.)
</p>
<p>
I would like a way around this problem. It seems like it would be enough to communicate the namespace to <tt>mkName</tt>, so that the ambiguity no longer exists.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4429#changelog
http://ghc.haskell.org/trac/ghc/ticket/4442
http://ghc.haskell.org/trac/ghc/ticket/4442#4442: Add unaligned version of indexWordArray#Tue, 26 Oct 2010 15:02:17 GMTtibbe<p>
<tt>indexWordArray#</tt> takes an offset in whole words, making it impossible to do unaligned reads on platforms that support such reads. This has performance implications for some programs e.g. implementations of MurmurHash.
</p>
<p>
I propose we add versions of <tt>indexWord*Array</tt> that take byte offsets. The user is responsible for only using those on platforms that support them and the implementation is free to crash if they're used elsewhere.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4442#changelog
http://ghc.haskell.org/trac/ghc/ticket/4453
http://ghc.haskell.org/trac/ghc/ticket/4453#4453: Allow specifying .hi files of imports on command line in batch modeFri, 29 Oct 2010 14:31:29 GMTduncan<p>
It is useful for a build agent (e.g. cabal, or makefile) to have full control over the search path. Reasons you might want to do this are below.
</p>
<p>
The way a build agent can do this is to instruct ghc not to do any searching at all, using the flag <tt>-i</tt> which sets the search path to empty. Then the build agent has to supply ghc with all the <tt>.hs</tt> files that are needed, e.g.:
</p>
<pre class="wiki">ghc --make -i Foo.hs Bar.hs
</pre><p>
(any imports outside of these modules, or the package modules will fail)
</p>
<p>
This no-search scheme works in <tt>--make</tt> mode but not in batch mode. For that we need to be able to say:
</p>
<pre class="wiki">ghc -i -c Foo.hs
ghc -i -c Bar.hs Foo.hi
</pre><p>
That is, we need to be able to specify the .hi files of imported modules on the command line.
</p>
<p>
A build agent may want to do this so that it is insulated from the particular choices of ghc's search path semantics and/or have different choices. For example, ghc prefers modules in local .hs/.hi files to package modules while the build agent may want the reverse in some circumstances.
</p>
<p>
Apart from search path policy, it makes sense for a build agent to take this approach simply for correctness and simplicity. A correct build agent must track dependencies absolutely precisely, so it has to know which specific .hi files ghc will pick anyway. It is simpler for the build agent to tell ghc those .hi files rather than trying to precisely arrange things to match ghc's search behaviour.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4453#changelog
http://ghc.haskell.org/trac/ghc/ticket/4459
http://ghc.haskell.org/trac/ghc/ticket/4459#4459: Polymorphic Data.DynamicSun, 31 Oct 2010 11:52:01 GMTvivian<p>
At some point in the compilation process an expression acquires a fully-specified, possibly polymorphic, type. If we add an operation that join that type and that expresssion, say <tt>TypedAny</tt>, then we can implement the part of <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4316" title="feature request: Interactive "do" notation in GHCi (new)">#4316</a> requested by mitar.
</p>
<p>
In GHCi we can evaluate <tt>HValue</tt>s <strong>and also</strong> string them together with <tt>bind</tt> statements.
</p>
<p>
The function
</p>
<pre class="wiki">applyDynamic :: TypedAny -> TypedAny -> Maybe TypedAny
</pre><p>
includes in its implementation a dictionary lookup and possible dynamic object linking for class methods.
</p>
<p>
the function
</p>
<pre class="wiki">fromDynamic :: TypedAny -> Maybe a
</pre><p>
like <tt>applyDynamic</tt>, runs the typechecker at runtime to unify (and possibly link) the dynamic type (TypedAny) and the static type (a).
</p>
<p>
<em>Conjecture </em> Since we already have <tt>typecase</tt> (classes), with type families, this feature provides/simulates dependent types.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4459#changelog
http://ghc.haskell.org/trac/ghc/ticket/4466
http://ghc.haskell.org/trac/ghc/ticket/4466#4466: Add extension for type applicationTue, 02 Nov 2010 19:48:41 GMTigloo<p>
In
<a class="ext-link" href="http://www.haskell.org/pipermail/libraries/2010-October/014761.html"><span class="icon"></span>http://www.haskell.org/pipermail/libraries/2010-October/014761.html</a>
we discussed adding an extension for explicit type application.
</p>
<p>
The main stumbling block is syntax.
</p>
<p>
For example, we would like to be able to write something to the effect of
</p>
<pre class="wiki">(Just @ Char) 'a'
</pre><p>
and also to be able to pattern match types, e.g.
</p>
<pre class="wiki">f ((Just @ t) x) = (Right @ String @ t) x
</pre><p>
For a more useful example:
</p>
<pre class="wiki">data T where
MkT :: forall a. a -> (a -> Int) -> T
f (MkT @ a x g) = g (x::a)
</pre><p>
Possible suggested syntaxes to make something of type
</p>
<pre class="wiki">Maybe (forall a. a->a)
</pre><p>
were:
</p>
<pre class="wiki">Just @ (forall a. a->a) id (@ has another meaning in patterns)
Just[forall a. a->a] id (pvs, opal, HasCASL with paramterized modules; conflicts with Haskell list syntax)
Just {forall a. a->a} id (Agda)
#Just (forall a. a->a) id
@Just (forall a. a->a) id (coq)
</pre><p>
In the last 2 cases we would presumably have something like
</p>
<pre class="wiki">Just :: forall a . a -> Maybe a
Just :: Char -> Maybe Char
#Just :: /\ a . a -> Maybe a
#Just Char :: Char -> Maybe Char
</pre><p>
and similarly
</p>
<pre class="wiki">#map :: /\ a b . (a -> b) -> [a] -> [b]
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/4466#changelog
http://ghc.haskell.org/trac/ghc/ticket/4479
http://ghc.haskell.org/trac/ghc/ticket/4479#4479: Add Type Directed Name ResolutionSat, 06 Nov 2010 19:50:22 GMTgidyn<p>
A request to implement <a class="ext-link" href="http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResolution"><span class="icon"></span>type-directed name resolution</a>, as <a class="ext-link" href="http://hackage.haskell.org/trac/haskell-prime/ticket/129"><span class="icon"></span>proposed</a> for Haskell'.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4479#changelog
http://ghc.haskell.org/trac/ghc/ticket/4520
http://ghc.haskell.org/trac/ghc/ticket/4520#4520: startup code on Windows should use SetDllDirectory("")Mon, 22 Nov 2010 16:14:30 GMTduncan<p>
See <a class="ext-link" href="http://blogs.msdn.com/b/oldnewthing/archive/2010/11/10/10088566.aspx"><span class="icon"></span>Raymond's blog</a> about (un)safe dll loading. He points to a <a class="ext-link" href="http://support.microsoft.com/kb/2389418"><span class="icon"></span>support article</a> which recommends that new programs use <tt>SetDllDirectory("")</tt> to prevent the problem (it's not the default because that'd break old programs).
</p>
<p>
In the GHC context, this could go in the startup code for standalone executables. It is a process-scope property so changing it is not appropriate for DLL startup.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4520#changelog
http://ghc.haskell.org/trac/ghc/ticket/4806
http://ghc.haskell.org/trac/ghc/ticket/4806#4806: Make error message more user friendly when module is not found because package is unusableTue, 30 Nov 2010 07:33:26 GMTmitar<p>
Make error message more user friendly when module is not found because package is unusable. Currently it just reports that module is missing (the same as it even would not be installed) but then checking with <tt>ghc-pkg find-module</tt> shows package correctly. Chasing '-v' output around can then show you this but it would be easier that you would immediately get a helpful message.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4806#changelog
http://ghc.haskell.org/trac/ghc/ticket/4815
http://ghc.haskell.org/trac/ghc/ticket/4815#4815: Instance constraints should be used when deriving on associated data typesFri, 03 Dec 2010 15:34:23 GMTbatterseapower<p>
Consider this program:
</p>
<pre class="wiki">{-# LANGUAGE TypeFamilies, FlexibleContexts #-}
class Eq (Associated a) => Foo a where
data Associated a
instance Foo a => Foo (Maybe a) where
data Associated (Maybe a) = AssociatedMaybe (Associated a)
deriving (Eq)
</pre><p>
This does not compile, giving this error message:
</p>
<pre class="wiki">
/Users/mbolingbroke/Junk/Repro.hs:9:40:
No instance for (Eq (Associated a))
arising from the 'deriving' clause of a data type declaration
at /Users/mbolingbroke/Junk/Repro.hs:9:40-41
Possible fix:
add an instance declaration for (Eq (Associated a))
or use a standalone 'deriving instance' declaration instead,
so you can specify the instance context yourself
When deriving the instance for (Eq (Associated (Maybe a)))
</pre><p>
However, this is surprising because I clearly state that a is Foo, and hence (Associated a) has an Eq instance by the superclass constraint on Foo.
</p>
<p>
If I point this out explicitly using standalone deriving it works:
</p>
<pre class="wiki">{-# LANGUAGE TypeFamilies, FlexibleContexts #-}
{-# LANGUAGE StandaloneDeriving, FlexibleInstances #-}
class Eq (Associated a) => Foo a where
data Associated a
instance Foo a => Foo (Maybe a) where
data Associated (Maybe a) = AssociatedMaybe (Associated a)
-- deriving (Eq)
deriving instance Foo a => Eq (Associated (Maybe a))
</pre><p>
So I think the default behaviour for "deriving" on an associated data family should be to include the constraints from the enclosing instance. For now the workaround is just to use standalone deriving.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4815#changelog
http://ghc.haskell.org/trac/ghc/ticket/4823
http://ghc.haskell.org/trac/ghc/ticket/4823#4823: Loop strength reduction for array indexingTue, 07 Dec 2010 16:46:09 GMTtibbe<p>
Indexing into a <tt>ByteArray#</tt> in a loop is currently more expensive than working on a <tt>ForeignPtr</tt> due to lack of strength reduction. Pointer arithmetic is cheaper than using base + offset indexing. We could convert indexing into pointer arithmetic if it weren't for the GC being able to move objects around.
</p>
<p>
Tom Rodriguez had the following to say about Java <a class="missing wiki">HotSpot?</a> and loop strength reduction:
</p>
<blockquote class="citation">
<p>
"The server compiler doesn't do explicit loop strength reduction though it can get a bit of it as a result of other transformations loop invariant code motion. I've played a bit with doing it more explicitly but had some difficulty getting benefit from it. The resulting pointers are handled by the notion of derived pointers. These are interior pointers that are tracked along with their base pointers. At the beginning of GC the offset from the base of the derived pointer is saved and the pointer is converted to the base and after GC the offset is added back in. That part all happens automatically. Searching for <a class="missing wiki">DerivedPointer?</a> will lead you to the relevant code."
</p>
</blockquote>
<p>
Perhaps it's an idea we could try?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4823#changelog
http://ghc.haskell.org/trac/ghc/ticket/4913
http://ghc.haskell.org/trac/ghc/ticket/4913#4913: Make event tracing conditional on an RTS flag onlyFri, 21 Jan 2011 13:53:00 GMTtibbe<p>
The current event tracing mechanism is enabled at link time by linking in one of two different versions of a C function, one being a no-op function. We could allow users to enable/disable tracing using a RTS flag instead, making event logging more convenient to use. At the same time we would introduce tracing levels.
</p>
<p>
Design:
</p>
<p>
Add a static memory location where the current tracing level is stored:
</p>
<pre class="wiki">uint tracelevel = 0;
</pre><p>
Modify <tt>GHC.Exts.traceEvent</tt> to read
</p>
<pre class="wiki">foreign import ccall unsafe "&tracelevel" :: Ptr Word
traceEvent :: String -> IO ()
traceEvent msg =
if unsafePerformIO (peek tracelevel) > 0
then do
withCString msg $ \(Ptr p) -> IO $ \s ->
case traceEvent# p s of s' -> (# s', () #)
else return ()
</pre><p>
and (optionally) add some more functions that log at different trace levels.
</p>
<p>
This should be no slower than the current system. With inlining this should result in a load and a branch at the call site. The load should be cheap as the value is likely to be in cache (as it never changes). The branch should be easy to predict as it's always the same. With some cooperation from the code generator we could make sure that the branch is always cheap.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4913#changelog
http://ghc.haskell.org/trac/ghc/ticket/4921
http://ghc.haskell.org/trac/ghc/ticket/4921#4921: report ambiguous type variables more consistentlyThu, 27 Jan 2011 07:21:18 GMTSaizan<pre class="wiki">{-# LANGUAGE MultiParamTypeClasses #-}
module Amb where
class C a b where
f :: (a,b)
instance C Int Char where
f = undefined
{-
x = fst f
/home/saizan/snippets/Amb.hs:7:8:
Ambiguous type variables `a', `b' in the constraint:
`C a b'
arising from a use of `f' at /home/saizan/snippets/Amb.hs:7:8
Possible cause: the monomorphism restriction applied to the following:
x :: a (bound at /home/saizan/snippets/Amb.hs:7:0)
Probable fix: give these definition(s) an explicit type signature
or use -XNoMonomorphismRestriction
Failed, modules loaded: none.
-}
{-
y = fst f :: Int
/home/saizan/snippets/Amb.hs:21:8:
No instance for (C Int b)
arising from a use of `f' at /home/saizan/snippets/Amb.hs:21:8
Possible fix: add an instance declaration for (C Int b)
In the first argument of `fst', namely `f'
In the expression: fst f :: Int
In the definition of `y': y = fst f :: Int
Failed, modules loaded: none.
-}
</pre><p>
Both x and y have the same problem, there isn't enough type information to let the typechecker decide on an instance, so it seems they should produce similar error messages.
</p>
<p>
In particular, the error for y is quite confusing since it can be reasonably interpreted as saying there's no type b for which there's an instance C Int b, which in fact is not true, so i think explicitly mentioning the ambiguity like in the first message would help many to understand the problem better.
</p>
<p>
I can see though that an "instance C Int b" could make sense, more often than C a b, so maybe "Possible fix: add an instance declaration for (C Int b)" should be conserved, even if it still has the problem of expressing that the second argument needs to be a variable.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4921#changelog
http://ghc.haskell.org/trac/ghc/ticket/4959
http://ghc.haskell.org/trac/ghc/ticket/4959#4959: Warning about variables with leading underscore that are used anywayMon, 14 Feb 2011 18:09:29 GMTLemming<p>
I use -Wall all the time, which includes -fwarn-unused-binds and -fwarn-unused-matches that warn about variable bindings that are not used. It already spotted lots of mistakes for me. You can suppress the warning by prepending an underscore '_' to a variable name. However, I have recently seen code, where variable names with leading underscores are regularly used, where other programmers might have chosen trailing underscores or primes. I suspect that the programmer was not aware, that he disabled warnings about unused bindings this way. Thus I like to have a warning about underscored variables that are used in the sense of the definition given for -fwarn-unused-binds in <a href="http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html">http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html</a>.
We still have to decide whether this warning should be part of -Wall or -fwarn-unused-binds or whether there should be a separate option like -fwarn-used-underscored-binds.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4959#changelog
http://ghc.haskell.org/trac/ghc/ticket/4980
http://ghc.haskell.org/trac/ghc/ticket/4980#4980: Warning about module abbreviation clashesThu, 24 Feb 2011 22:12:46 GMTLemming<p>
Please add the option -fwarn-module-rename-collision that makes GHC to do the following: If GHC encounters an import situation like
</p>
<pre class="wiki">module Main where
import qualified Data.A as A
import qualified Control.A as A
</pre><p>
then GHC should emit a warning like
</p>
<pre class="wiki">Main.hs:3:0:
Main.hs:4:0:
Warning: Both Data.A and Control.A are renamed to A.
An identifier like A.ident can only be resolved,
if it is either in Data.A or Control.A.
Better rename both modules to different names.
</pre><p>
Reason for this warning is, that if 'ident' is from Data.A as of writing Main, and later another variable named 'ident' is added to Control.A, then A.ident can no longer be resolved in Main. That is, by accidental module rename collisions even qualified imports carry the risk of future name collisions.
</p>
<p>
Related to <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4977" title="feature request: Warning about unqualified implicit imports (closed: fixed)">#4977</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4980#changelog
http://ghc.haskell.org/trac/ghc/ticket/5016
http://ghc.haskell.org/trac/ghc/ticket/5016#5016: Make Template Haskell: -ddump-splices generate executable codeSat, 12 Mar 2011 01:15:12 GMTguest<p>
<a class="ext-link" href="http://hpaste.org/44711/testsunpackedhs"><span class="icon"></span>http://hpaste.org/44711/testsunpackedhs</a>
</p>
<p>
I am Aur Saraf, reachable sonoflilit @ don't-be-evil.
</p>
<p>
I wanted to edit some code that was autogenerated by TH with Michael Snoyman's Persistent library (version 0.3.1.3).
</p>
<p>
So I ran it through ghc --make -ddump-splices 2>&1 | less, and in a copy of my original file replaced the TH with the splices.
</p>
<p>
It wouldn't compile, so I googled like crazy and eventually asked for help on #haskell, where the kindly kmc helped me get it to compile.
</p>
<p>
We identified several inaccuracies in the pretty printer.
</p>
<p>
I had to do a few things, among them:
</p>
<ul><li>Delete some instances of the keyword "instance":
<pre class="wiki">02:12 < kmc> oh, i think the problem is simply that you don't use the kw "instance" for associated types
02:12 < kmc> only for standalone family instances
02:12 < kmc> sorry i didn't remember that earlier
02:13 < kmc> so ghc / TH is being imprecise with how it outputs generated asstype instances
[..]
02:14 < kmc> well splices generate abstract syntax trees
02:15 < kmc> and i guess the AST for a family instance inside or outside a class instance is the same
02:15 < kmc> but the concrete syntax differs
02:15 < kmc> and the pretty-printer for that AST is not taking that into account
</pre></li></ul><ul><li>Change many illegal identifiers:
<pre class="wiki">01:51 < kmc> sonoflilit, it looks like TH is generating names of the form x[a2ur]
01:51 < kmc> which aren't valid Haskell identifiers
01:52 < kmc> i don't know if that's related to your problem
01:52 < kmc> but it seems to be a reason why this dumped splice won't work as-is
</pre></li></ul><ul><li>Remove {}s:
<pre class="wiki">02:23 < sonoflilit> { entityDef _ = Database.Persist.Base.EntityDef
02:24 < sonoflilit> TestsUnpacked.hs:47:4: parse error on input `{'
02:25 < kmc> oh i think "entityDef _ = ..." starts off the methods part of the type class instance
02:25 < kmc> so that brace should move to right after "instance PersistEntity Person where"
02:25 < kmc> or probably, not exist
</pre>(also, in other parts of the file)
</li></ul><ul><li>Fix empty data declarations:
<pre class="wiki">02:24 < kmc> at line 137-139 you have three "data instance"s with no right-hand side
02:26 < kmc> does "data Foo =" actually work
02:26 < kmc> as an alternative to "data Foo"
02:27 < sonoflilit> hmm, tested, no
02:27 < sonoflilit> and you need a special extension to allow "data Foo"
</pre>(I needed to <tt>{-# LANGUAGE EmptyDataDecls #-}</tt>, as well as remove the "=" from the lines)
</li></ul><ul><li>Change some wacky syntax:
<pre class="wiki">02:33 < sonoflilit> kmc: what's wrong with my line 192's ->?
02:33 < sonoflilit> It gives an error after I solved all the { errors
02:36 < kmc> sonoflilit, not sure... try rewriting that pattern as ((x_a3pU,_):_)
02:37 < kmc> that use of qualified infix *should* work
02:37 < kmc> also it keeps using { } to override layout but then not inserting ;
02:39 < kmc> oh "GHC.Types.[]"
02:39 < kmc> probably isn't right
02:40 < kmc> unqualify that mo'fo'
</pre></li></ul><ul><li>Add all sorts of imports:
<pre class="wiki">TestsUnpacked.hs:21:19:
Not in scope: type constructor or class `GHC.Int.Int64'
TestsUnpacked.hs:31:18:
Not in scope:
type constructor or class `Web.Routes.Quasi.Classes.SinglePiece'
[..]
TestsUnpacked.hs:186:20:
Not in scope: data constructor `Database.Persist.Base.SqlString'
TestsUnpacked.hs:187:26:
Not in scope:
data constructor `Database.Persist.Base.PersistString'
</pre></li></ul><ul><li>Copy code from a library because it was private:
<pre class="wiki">TestsUnpacked.hs:67:29: Not in scope: `Database.Persist.TH.apE'
</pre></li></ul><ul><li>Add parentheses to type constructor definitions:
<pre class="wiki">TestsUnpacked.hs:40:24:
`Maybe' is not applied to enough type arguments
PersonColorEq Maybe String |
becomes
PersonColorEq (Maybe String) |
</pre></li></ul><ul><li>Eventually I gave up at:
<pre class="wiki">TestsUnpacked.hs:61:4:
The equation(s) for `toPersistFields' have four arguments,
but its type `Person -> [SomePersistField]' has only one
In the instance declaration for `PersistEntity Person'
TestsUnpacked.hs:87:4:
The equation(s) for `persistUpdateToValue' have two arguments,
but its type `Update Person -> PersistValue' has only one
In the instance declaration for `PersistEntity Person'
</pre></li></ul><p>
What I'd recommend the person who takes this bug is to follow my steps to reproduce and then again and again until the file compiles with as few manual changes as possible (perhaps the added language extension and imports are unavoidable, all else is clearly a bug).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5016#changelog
http://ghc.haskell.org/trac/ghc/ticket/5059
http://ghc.haskell.org/trac/ghc/ticket/5059#5059: Pragma to SPECIALISE on value argumentsTue, 29 Mar 2011 08:34:49 GMTbatterseapower<p>
I've sometimes found myself wishing for this pragma to get some "partial evaluation on the cheap". The idea is to allow something like:
</p>
<pre class="wiki">defaultOpts :: Options
defaultOpts = ...
{-# SPECIALISE f defaultOpts :: Int -> Int #-}
f :: Options -> Int -> Int
f opts x = ... f opts ...
</pre><p>
This would desugar into this additional code:
</p>
<pre class="wiki">{-# RULES "f/spec" f defaultOpts = f_spec_1 #-}
f_spec_1 = (\opts x -> ... ... f opts ...) defaultOpts -- NB: body of f duplicated
</pre><p>
The hope is that the simplifier and RULE matcher will tidy this up so we get a nice loop back to f_spec_1 with the body of the function specialised for the particular opts.
</p>
<p>
This is useful when functions are called often with particular arguments. An example would be where "f" is an edit-distance function which takes costs to be assigned to each edit, strings to be compared and returns an integer distance. In my library, the costs are given almost always going to be the default ones so I want to make that case fast, but I want to allow the user to supply their own set.
</p>
<p>
This pragma is somewhat subsumed by:
</p>
<ol><li><a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/SpecConstr">SpecConstr</a>, if the options are algebraic data/literals that are also scrutinised by the body of f
</li></ol><ol start="2"><li>Static argument transformation, except that the RULE based strategy achieves more code sharing compared to SAT
</li></ol><p>
I think that pragma might be a relatively simple to implement nice-to-have feature.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5059#changelog
http://ghc.haskell.org/trac/ghc/ticket/5082
http://ghc.haskell.org/trac/ghc/ticket/5082#5082: Emit warnings when conflicting flags are suppliedSun, 03 Apr 2011 13:10:54 GMTezyang<p>
Many command line flags can be thought of as modifying some GHC's internal flag state. We do this so that we can override flags in one place by re-specifying the flag later, e.g. ghc -fno-new-codegen ... -fnew-codegen
</p>
<p>
While this is handy, it can cause some interesting unexpected behavior where a user modifies a flag in some place (for example, the command line), and the flag gets subsequently overridden by another location (for example, an OPTIONS_GHC pragma). What would be useful is if GHC could report when some internal option is modified by multiple places, and say which one "won" in the end.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5082#changelog
http://ghc.haskell.org/trac/ghc/ticket/5171
http://ghc.haskell.org/trac/ghc/ticket/5171#5171: Misfeature of Cmm optimiser: no way to extract a branch of expression into a separate statementFri, 06 May 2011 10:14:36 GMTrtvd<p>
AFAIK, optimisations in Cmm are performed using cmmMachOpFold.
However, this function is pure and does not allow detaching a branch of expression in order to make sure that it is executed only once.
</p>
<p>
Let's say we have (Op1 arg1 arg2) and we want to transform it to (Op2 arg1 (Op3 arg2 arg1)). Doing this would mean that arg1 would be computed more than once. Instead, the following should be possible:
</p>
<pre class="wiki">arg1_reg <- arg1
(Op2 arg1_reg (Op3 arg2 arg1_reg))
</pre><p>
The lack of this feature already stops one of optimisations from happening in most cases. See:
</p>
<pre class="wiki"> CmmReg _ <- x -> -- We duplicate x below, hence require
-- it is a reg. FIXME: remove this restriction.
</pre><p>
in <a class="missing wiki">CmmOpt?</a>.hs.
</p>
<p>
There is a number of other useful optimisations which can be implemented only with this feature available.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5171#changelog
http://ghc.haskell.org/trac/ghc/ticket/5197
http://ghc.haskell.org/trac/ghc/ticket/5197#5197: Support static linker semantics for archives and weak symbolsFri, 13 May 2011 19:16:41 GMTduncan<p>
While looking at <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/5004" title="bug: loading stripped libHsghc-7.0.2.a fails (closed: fixed)">#5004</a>, I had a go at getting the GHCi linker to load the LLVM libs, as in making this work: <tt>ghci -package llvm</tt>.
</p>
<p>
This involves loading a whole bunch of LLVM*.a files and linking them against the C and C++ standard libs. This in turn requires a few more features in the GHCi linker:
</p>
<ul><li>support for weak symbols
</li><li>search archives only on demand
</li><li>support .oS files in archives
</li></ul><p>
The last is trivial.
</p>
<p>
The first is not so hard to do. When the linker finds a definition of a weak symbol, if there's already a symbol with that name in the symbol table then we just ignore the new one. When resolving symbols if we find an unresolved weak symbol we just give it the value zero. Doing this is enough to load .e.g libstdc++.a and libc.a (rather than libc.so).
</p>
<p>
The next part is a bit more work. When you give system static linker some .a files, it only uses them to provide definitions for unresolved symbols in the main target. In particular it is fine for two .a files to provide definitions of the same symbol because the linker just looks for the first. (This is in contrast to duplicate symbols in the main .o input files). On linux, both libm and libc define some of the same symbols, such as <tt>__isinf</tt>.
</p>
<p>
Similarly, there is a problem that the GHCi linker predefines the <tt>atexit</tt> symbol, but that is also defined by <tt>libc.a</tt>.
</p>
<p>
So for the GHCi linker to load both libm and libc then it has to follow the standard semantics for linking archives. Currently it treats an archive as a request to link all the .o files in that archive.
</p>
<p>
Probably it is not sensible to go as far as implementing the full standard static linking semantics in the GHCi linker. It's of somewhat questionable value since we mainly need it for linking Haskell code, not C/C++ code.
</p>
<p>
Nevertheless, if we do need this, then the attached Linker.c has a partial implementation. It does the weak symbols and <tt>.oS</tt> files in archives.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5197#changelog
http://ghc.haskell.org/trac/ghc/ticket/5219
http://ghc.haskell.org/trac/ghc/ticket/5219#5219: need a version of hs_init that returns an error code for command-line errorsWed, 25 May 2011 15:25:42 GMTsimonmar<p>
This ticket is extracted from Roman's comment in <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/4464" title="bug: RTS options broken for dynamic libraries (closed: fixed)">#4464</a>:
</p>
<p>
<tt>hs_init</tt> simply aborts if it doesn't like the RTS arguments which is quite unhelpful for dynamic libraries. I took me a day to find out that an application crash was caused by a failing hs_init (because of the -rtsopts problem). I would like to add a check for this to our code but there doesn't seem to be a way to do this. It would be much nicer if hs_init returned a failure/success code, at least for dynamic libraries.
</p>
<p>
To which I responded:
</p>
<p>
If hs_init needs to return an error condition rather than aborting, then we need to define a new API for that, and fix setupRtsFlags. I don't think we need to do this for every case of stg_exit and certainly not for barf: these are all internal error conditions and we have no sensible way to recover.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5219#changelog
http://ghc.haskell.org/trac/ghc/ticket/5248
http://ghc.haskell.org/trac/ghc/ticket/5248#5248: Infer type context in a type signatureThu, 09 Jun 2011 19:02:22 GMTgidyn<p>
If I have code such as
</p>
<pre class="wiki">class Foo f where
foo :: a -> f a
data Bar f a = Foo f => Bar {bar :: f a}
instance Foo (Bar f) where
foo a = Bar (foo a)
</pre><p>
GHC will demand <tt>Foo f =></tt> on the instance declaration, even though this can be inferred from the definition of Bar.
</p>
<p>
I understand <em>why</em> this is happening, but it should not be necessary to repeat information already given. Some code violates DRY dozens of times because of this limitation.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5248#changelog
http://ghc.haskell.org/trac/ghc/ticket/5266
http://ghc.haskell.org/trac/ghc/ticket/5266#5266: Licensing requirements and copyright noticesSun, 19 Jun 2011 17:50:13 GMThoueland<p>
I'm not sure where or how to bring this up, but I figured I would inform you that complying with the licensing requirements to distribute executables programmed in Haskell (using GHC) seems to be tiresome.
</p>
<p>
I have a personal project written in Haskell and Lua, and I recently tried to make sure that I comply with the necessary requirements to distribute it. My result was a 1660-line copyright file (<a class="ext-link" href="http://www.houeland.com/kol/docs/copyright"><span class="icon"></span>http://www.houeland.com/kol/docs/copyright</a>), which I believe is excessive.
</p>
<p>
This mostly stems from the use of BSD-style licenses for libraries, which require copyright notices to be reproduced for redistributions in binary form.
</p>
<p>
Many of them are based on code from the GHC project + the Haskell 98 Report + the Haskell Foreign Function Interface specification. I think it would be nice if at least those parts could clearly be distributed using only one reproduction of the GHC license (including allowing derived binary forms to not include the restrictions against claiming to be definitions of the Haskell 98 Language / Foreign Function Interface). Currently the GHC-based libraries have licenses that say they're derived from GHC and include the GHC license notice. The libraries are listed as BSD3 in cabal files, but it's not clear to me that the statement actually covers licensing for the entirety of the library (developments after the split), and whether all GHC-based libraries can currently be distributed using a single copyright notice.
</p>
<p>
Generally, many of the other available Haskell libraries also seem to use BSD-style licenses, which can be a hassle to comply with for binary redistributions, mostly when dependencies also use separate BSD-style licenses that must be included. Having a 'default' license in the Haskell community that's similar to Boost or zlib instead of BSD3 might be preferable for the many smaller libraries available. Many of the libraries actually have different licenses (but similar ones such as MIT, or people modifying parts of their license file) while being listed as BSD3 in cabal files.
</p>
<p>
I don't know exactly what you can do about this, but an easier licensing landscape for binary redistributions would certainly be nice. (And possibly tools for automatically listing licensing restrictions and producing copyright notices accurately.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5266#changelog
http://ghc.haskell.org/trac/ghc/ticket/5273
http://ghc.haskell.org/trac/ghc/ticket/5273#5273: error and undefined should print a locationFri, 24 Jun 2011 18:50:14 GMTaugustss<p>
The Control.Exception.assert function has a very nice hack so it prints a location together with the message. Could we please have that feature for 'error' and 'undefined' as well?
</p>
<p>
I just had the case where in one of 83 installed packages some idiot has an error message that just says 'dataTypeConstrs', which makes it very tedious to figure out what to fix. Yes, I can recompile everything for profiling, but that takes another two hours, which is why I'd prefer location information. (BTW, hbc had location info for those.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5273#changelog
http://ghc.haskell.org/trac/ghc/ticket/5288
http://ghc.haskell.org/trac/ghc/ticket/5288#5288: Less noisy version of -fwarn-name-shadowingTue, 28 Jun 2011 22:26:26 GMTbatterseapower<p>
I would like a flag that warns about name-shadowing in more restricted circumstances than the current flag. I.e. I would like examples like these not to produce a warning:
</p>
<pre class="wiki">foo x = ..
where
bar x = ...
</pre><pre class="wiki">baz z = do
z <- .... z ...
return z
</pre><p>
But I would like these to produce one:
</p>
<pre class="wiki">foo x = ..
where
x = ... x ...
</pre><pre class="wiki">baz z = mdo
z <- .... z ...
return z
</pre><p>
Basically warn when a definition shadows *itself*. My motivation is that code like my first two examples is almost never an error in my experience, but my last two examples almost always are examples of my accidentally building a loop that evaluates to _|_.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5288#changelog
http://ghc.haskell.org/trac/ghc/ticket/5296
http://ghc.haskell.org/trac/ghc/ticket/5296#5296: Add explicit type applicationsSun, 03 Jul 2011 17:30:35 GMTdsf<p>
This example is derived from code in my application. It works, but I can't add a signature to it. In other places it is preventing some code from compiling at all.
</p>
<pre class="wiki">{-# LANGUAGE KindSignatures, MultiParamTypeClasses, RankNTypes #-}
{-# OPTIONS -Wall #-}
module Test where
class C t1 t2 m where method :: Int -> m t2
f :: forall t1 t2 (m :: * -> *). C t1 t2 m => Int -> m t2
f x = method x
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/5296#changelog
http://ghc.haskell.org/trac/ghc/ticket/5918
http://ghc.haskell.org/trac/ghc/ticket/5918#5918: hsc2hs forces wordsize (i.e. -m32 or -m64) to be the choice of GHC instead of allowing a different (or no/default choice)Wed, 07 Mar 2012 21:56:09 GMTAtze<p>
I am not sure whether to call this a bug as it does not cause a failure of GHC but a failure of UHC which also uses hsc2hs.
</p>
<p>
The problem occurs when UHC builds for a different wordsize than GHC, in particular UHC 64 bits, GHC 32 bits. The wrapper then forces -m32 when running hsc2hs via the environment variable HSC2HS_EXTRA. This cannot be turned off. A (temporary) solution is to uncomment the following lines in the wrapper script /usr/bin/hsc2hs:
</p>
<pre class="wiki"># -c*) HSC2HS_EXTRA=;;
# --cc=*) HSC2HS_EXTRA=;;
</pre><p>
This turns off the extra flags when a C compiler is explicitly specified, amongst which the -m32, and just lets the user define (or not define) the required flags when another compiler is explicitly used.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/5918#changelog
http://ghc.haskell.org/trac/ghc/ticket/7977
http://ghc.haskell.org/trac/ghc/ticket/7977#7977: Optimization: Shift dropped list heads by coeffecient to prevent thunk generationTue, 11 Jun 2013 14:50:18 GMTschyler<p>
Consider the following snippet(s) equivalent to ([a..b] !! n), the source of (!!) and the source of drop:
</p>
<pre class="wiki">normal_list :: Int -> Int
normal_list n = head $ drop n [a..b]
shifted_list :: Int -> Int
shifted_list n = head $ drop (n-n) [(a+n)..b]
</pre><pre class="wiki">xs !! n | n < 0 = undefined
[] !! _ = undefined
(x:_) !! 0 = x
(_:xs) !! n = xs !! (n-1)
</pre><pre class="wiki">drop n xs | n <= 0 = xs
drop _ [] = []
drop n (_:xs) = drop (n-1) xs
</pre><p>
Notice the (_:xs) matching in these functions as a result of WHNF.
</p>
<p>
In the first case, normal_list, thunks are generated for x in ({-x-}_:xs) of the target list and overhead is seen in the pattern matching/guard of n in drop.
</p>
<p>
In the second case, shifted_list, this overhead can be completely removed by adding a coefficient such that the list starts at the programmatically defined lower bound, a, plus the known fact that the head is dropped n times.
</p>
<p>
Hence, given the example above, consider:
</p>
<pre class="wiki">[x * x + 3 | x <- [1..]] !! n
-- versus
[x * x + 3 | x <- [(1+n)..]] !! (n-n)
-- which is optimized into
[x * x + 3 | x <- [(n+1)..]] !! 0
-- which is effectively
head [x * x + 3 | x <- [(n+1)..]]
</pre><p>
The operation is turned from O(n) into O(1).
</p>
<p>
Consider benchmark proving GHC 7.4.2 does not make this optimization under -O2:
</p>
<pre class="wiki">import Criterion.Main
normal_list :: Int -> Int
normal_list n = head $ drop n [1..]
shifted_list :: Int -> Int
shifted_list n = head $ drop (n-n) [(1+n)..]
main = defaultMain
[ bench "normal_list 1000" $ whnf normal_list 1000
, bench "shifted_list 1000" $ whnf shifted_list 1000
]
</pre><pre class="wiki">C:\Users\Kyle\Desktop>ghc -O2 listco.hs
[1 of 1] Compiling Main ( listco.hs, listco.o )
Linking listco.exe ...
C:\Users\Kyle\Desktop>listco.exe
warming up
estimating clock resolution...
mean is 4.644044 us (160001 iterations)
found 319255 outliers among 159999 samples (199.5%)
159256 (99.5%) low severe
159999 (100.0%) high severe
estimating cost of a clock call...
mean is 310.3118 ns (34 iterations)
benchmarking normal_list 1000
Warning: Couldn't open /dev/urandom
Warning: using system clock for seed instead (quality will be lower)
mean: 7.352463 us, lb 7.058339 us, ub 7.646574 us, ci 0.950
std dev: 1.478087 us, lb 1.478066 us, ub 1.478200 us, ci 0.950
variance introduced by outliers: 94.651%
variance is severely inflated by outliers
benchmarking shifted_list 1000
mean: 46.42819 ns, lb 45.44244 ns, ub 47.21689 ns, ci 0.950
std dev: 4.495757 ns, lb 4.035428 ns, ub 4.832396 ns, ci 0.950
variance introduced by outliers: 77.960%
variance is severely inflated by outliers
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/7977#changelog
http://ghc.haskell.org/trac/ghc/ticket/8161
http://ghc.haskell.org/trac/ghc/ticket/8161#8161: Associated type parameters that are more specific than the instance headerFri, 23 Aug 2013 12:45:59 GMTadamgundry<p>
It would be nice if type parameters of associated types could be more specific than those in the instance header. This is currently rejected with the message "Type indexes must match class instance head", but could be accepted:
</p>
<pre class="wiki">{-# LANGUAGE TypeFamilies #-}
class C a where
type T a
instance C [a] where
type T [Bool] = Int
type T [Int] = Int
</pre><p>
More typically, this is useful where we want to use an equality constraint to make type inference easier, but need to match on the actual type in an associated type:
</p>
<pre class="wiki">{-# LANGUAGE TypeFamilies, FlexibleInstances #-}
class C a where
type T a
instance a ~ [b] => C a where
type T [b] = Int
</pre><p>
This showed up in the implementation of <a class="wiki" href="http://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan">OverloadedRecordFields</a>. Of course, one can always work around it using a normal (non-associated) type family.
</p>
<p>
Note that we already allow type families to specialise variables that do not occur in the instance header:
</p>
<pre class="wiki">{-# LANGUAGE TypeFamilies #-}
class C a where
type T a b
instance C [a] where
type T [a] [Bool] = Bool
type T [a] [Int] = Int
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/8161#changelog
http://ghc.haskell.org/trac/ghc/ticket/8207
http://ghc.haskell.org/trac/ghc/ticket/8207#8207: Pretty Printer for textual version of Language (name) in DynFlagsSun, 01 Sep 2013 03:02:13 GMTFuuzetsu<p>
I feel that the GHC API could benefit from a Show instance for Language in <a class="missing wiki">DynFlags?</a>.hs.
</p>
<p>
Currently, if we want to display the language being used we have to do something like
</p>
<pre class="wiki"> foo inf = case hmi_language inf of
Nothing -> Nothing
Just Haskell98 -> Just "Haskell98"
Just Haskell2010 -> Just "Haskell2010"
</pre><p>
This is pretty much just the Show instance (over Maybe) and Haskell can derive it for us automatically: we just need to change <tt>deriving Enum</tt> to <tt>deriving (Enum, Show)</tt>. The above solution is not the most robust ever as if this data type is ever changed, this starts to form an incomplete pattern. If we have a catch all <tt>_</tt>, GHC complains about overlapping patterns. Easily solved with <tt>show <$> hmi_language inf</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8207#changelog
http://ghc.haskell.org/trac/ghc/ticket/8441
http://ghc.haskell.org/trac/ghc/ticket/8441#8441: Allow family instances in an hs-boot fileSun, 13 Oct 2013 03:28:36 GMTgoldfire<p>
Compiling an .hs-boot file with a data instance leads to this error:
</p>
<pre class="wiki"> Illegal family instance in hs-boot file
</pre><p>
Yet, data instances make good sense in an hs-boot file, in case another module wants to access a constructor declared in the instance.
</p>
<p>
Furthermore, it may sometimes be desirable to allow type family instances in a hs-boot file, as well, in case some including modules need the instance for type simplification.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8441#changelog
http://ghc.haskell.org/trac/ghc/ticket/8516
http://ghc.haskell.org/trac/ghc/ticket/8516#8516: Add (->) representation and the Invariant class to GHC.GenericsSat, 09 Nov 2013 20:39:41 GMTnfrisby<p>
We currently disallow any use of the parameter in the domain of (->).
</p>
<pre class="wiki">newtype F a = F ((a -> Int) -> Int) deriving Generic1
<interactive>:4:38:
Can't make a derived instance of `Generic1 (F g)':
Constructor `F' must use the last type parameter only as the last argument of a data type, newtype, or (->)
In the data declaration for `F'
</pre><p>
DeriveFunctor succeeds for this F.
</p>
<p>
I'd like to add this representation type to GHC.Generics and DeriveGeneric.
</p>
<pre class="wiki">newtype (f :->: g) a = FArrow1 (f a -> g a)
</pre><p>
We could then represent the first example above. We could also derive the more interesting Generic1 (F g).
</p>
<pre class="wiki">newtype F g a = F (g a -> Int) deriving Generic1
type instance Rep1 (F g) = Rec1 g :->: Rec0 Int
instance Generic1 (F g) where
to x = F $ unRec0 . unArrow1 x . Rec1
from (F x) = FArrow1 $ Rec0 . x . unRec1
</pre><p>
Admittedly, there's not many generic definitions impeded by not having (:->:). Contra- and in-variant types are uncommon.
</p>
<p>
I'm suggesting this feature without strong motivating examples because I think this would streamline the implementation of -XDeriveGenerics in some ways while also making it more general — assuming that we added the Invariant class to base or ghc-prim.
</p>
<pre class="wiki">class Invariant t where
invmap :: (a -> b) -> (b -> a) -> t a -> t b
invmap_covariant :: Functor t => (a -> b) -> (b -> a) -> t a -> t b
invmap_covariant f _ = fmap f
instance (Invariant f,Invariant g) => Invariant (FArrow f g) where
invmap co contra (FArrow h) = FArrow $ invmap co contra . h . invmap contra co
</pre><p>
(Of course, Invariant should be a super class of Functor. :/ )
</p>
<p>
Now we can handle quite involved examples:
</p>
<pre class="wiki">newtype F g h a = F (g (h a)) deriving Generic1
instance Invariant g => Generic1 (F g h) where
to x = invmap unRec1 Rec1 $ unComp1 x
from (F x) = Comp1 $ invmap Rec1 unRec1
</pre><p>
All of that said, I'm mostly opening this ticket so I can get feedback on difficulties I might not be anticipating and have a place to reference from the compiler source code comments.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8516#changelog
http://ghc.haskell.org/trac/ghc/ticket/8593
http://ghc.haskell.org/trac/ghc/ticket/8593#8593: vector is being built even with `--no-dph`Tue, 03 Dec 2013 16:31:31 GMTnomeata<p>
I usually use <tt>./sync-all --no-dph get</tt> to speed up things a bit. But packages <tt>vector</tt>, <tt>primitive</tt> and <tt>random</tt> are still being pulled (by virtue of being submodules), and then built.
</p>
<p>
It would be nice if the build system would build them only if <tt>libraries/dph</tt> is available, or have another way of making them optional.
</p>
<p>
(Potentially obsolete once <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/8545" title="task: Reorganize Git repositories (new)">#8545</a> is done.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8593#changelog
http://ghc.haskell.org/trac/ghc/ticket/8707
http://ghc.haskell.org/trac/ghc/ticket/8707#8707: Kind inference fails in data instance definitionMon, 27 Jan 2014 18:03:30 GMTgoldfire<p>
Consider the following shenanigans:
</p>
<pre class="wiki">{-# LANGUAGE DataKinds, PolyKinds, TypeFamilies, GADTs #-}
data family SingDF (a :: (k, k2 -> *))
data Ctor :: k -> *
data instance SingDF (a :: (Bool, Bool -> *)) where
SFalse :: SingDF '(False, Ctor)
</pre><p>
HEAD reports (with <tt>-fprint-explicit-kinds</tt>)
</p>
<pre class="wiki"> Data constructor ‛SFalse’ returns type ‛SingDF
Bool k '('False, Ctor k)’
instead of an instance of its parent type ‛SingDF Bool Bool a’
In the definition of data constructor ‛SFalse’
In the data instance declaration for ‛SingDF’
</pre><p>
I see two problems here:
</p>
<p>
1) Kind inference should fix the problem. If I add a kind annotation to <tt>Ctor</tt>, the code works. GHC should be able to infer this kind annotation for me.
</p>
<p>
2) The error message is not particularly helpful. GHC 7.6.3 had a more verbose, but more helpful message.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8707#changelog
http://ghc.haskell.org/trac/ghc/ticket/8997
http://ghc.haskell.org/trac/ghc/ticket/8997#8997: Warn about unused parameters in recursive definitionsTue, 15 Apr 2014 08:54:09 GMTnomeata<p>
I’m correcting student’s exams right now; a good source of bad programs :-)
</p>
<p>
Consider this program:
</p>
<pre class="wiki">foo _ y [] = y
foo z y (_:xs) = foo z y xs
</pre><p>
It would be nice if GHC would warn that the first parameter of <tt>foo</tt> is not used. IIRC GHC warns about unused constructors even when they occur on RHSs.
</p>
<p>
If <tt>foo</tt> is passed to some higher order function that expects a particular type, removing the parameter would require a wrapper for there, or at least an anonymous lambda... but it’s probably still worth notifying the programmer, as more likely there is a bug or misunderstanding in such code.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/8997#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/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/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/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/1476
http://ghc.haskell.org/trac/ghc/ticket/1476#1476: Template Haskell: splicing types and patternsSun, 01 Jul 2007 11:53:44 GMTigloo<p>
In <a class="ext-link" href="http://www.haskell.org/pipermail/template-haskell/2003-February/000021.html"><span class="icon"></span>http://www.haskell.org/pipermail/template-haskell/2003-February/000021.html</a> Simon Peyton Jones writes:
</p>
<pre class="wiki">We claim to allow you to write splices in (a) types and (b) patterns.
I'm very dubious about (b). Consider]
x = 4
y :: Patt
y = [p| ... |]
f $y = x
Question: where is x bound? It looks as though x can be bound by the
spliced-in pattern or by the top-level binding. You can't tell without
knowing what $y expands to. We argue in our paper against non-top-level
declaration splices because that would lead to ambiguity of exactly this
sort.
It turns out that it's very inconvenient to implement pattern splices in
GHC, for exactly this reason. We can't figure out the binding structure
till we expand the splice. We can't expand the splice till typechecking
time. But the renamer currently fixes the binding structure before type
checking. Changing this would be a big upheaval.
Conclusion: pattern splices are hard to implement, and dubious from a
programming point of view. I propose to drop them, for now at least.
Type splices have some similar echoes. Consider
y :: Type
y = [t| a -> a |]
f :: $y
What is f polymorphic in? The trouble concerns Haskell's implicit
quantification. I guess there are three possibilities:
a) $y expands to "a -> a", and that is implicitly universally quantified
to "forall a. a->a".
b) The implicit quantification happens at the [t| ...|] brackets, so
that $y expands to
"forall a. a->a"
c) $y expands to "a -> a" with no implicit quantification anywhere.
I'm pretty sure that we should adopt (b). After all, we want a
lexical-scoping rule for TH, so we have to say where 'a' is bound.
That would still in principle allow
y :: Type
y = return (Tvar "a" `Arrow` Tvar "a")
Since it's the renamer that does implicit quantification, it'd be quite
awkward to make the implicit quantification at the splice site "see" the
free variables 'a'.
The link with the pattern stuff is this. If you see
f :: $y -> b
then what are the implicit for-alls? My answer: the implicit for-alls
are just for "b", not for any free vars of $y.
</pre><p>
Since then, the only solution for pattern splices I recall seeing is
</p>
<pre class="wiki">f ${x,z}y = x
</pre><p>
which asserts that the splice introduces the set of identifiers <tt>{x,z}</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1476#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/1928
http://ghc.haskell.org/trac/ghc/ticket/1928#1928: Confusing type error messageSun, 25 Nov 2007 14:44:33 GMTjosef<p>
The following code (which is part of a bigger module) needs scoped type variables to compile.
</p>
<pre class="wiki">run_state :: forall a s. State s a -> s -> (a,s)
run_state m s = observe_monad unit_op bind_op m where
unit_op v = (v,s)
bind_op :: BindOp (StateE s) a (a,s)
bind_op Get k = run_state (k s) s
bind_op (Put s1) k = run_state (k ()) s1
</pre><p>
However, forgetting to turn on scoped type variables will give a very confusing error message:
</p>
<pre class="wiki">Unimo.hs:56:36:
Couldn't match expected type `s1' against inferred type `s'
`s1' is a rigid type variable bound by
the type signature for `bind_op' at Unimo.hs:55:28
`s' is a rigid type variable bound by
the type signature for `run_state' at Unimo.hs:52:22
In the first argument of `k', namely `s'
In the first argument of `run_state', namely `(k s)'
In the expression: run_state (k s) s
</pre><p>
Line 52 is the type signature of run_state and line 55 is the type signature of bind_op. The error message talks about a type variable `s1' which isn't mentioned anywhere. I guess the reason for this is that we have name collision and this is ghc's way of trying to tell the two variables apart. I don't think it works that well though. But I'm afraid I don't have any suggestion on how to make it better.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1928#changelog
http://ghc.haskell.org/trac/ghc/ticket/2182
http://ghc.haskell.org/trac/ghc/ticket/2182#2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instancesFri, 28 Mar 2008 00:07:54 GMTclaus<pre class="wiki">$ compiler/stage2/ghc-inplace --interactive
GHCi, version 6.9.20080317: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
Prelude> :i Functor
class Functor f where fmap :: (a -> b) -> f a -> f b
-- Defined in GHC.Base
instance Functor Maybe -- Defined in Data.Maybe
instance Functor [] -- Defined in GHC.Base
instance Functor IO -- Defined in GHC.IOBase
Prelude> fmap not (True,True)
<interactive>:1:0:
No instance for (Functor ((,) Bool))
arising from a use of `fmap' at <interactive>:1:0-19
Possible fix: add an instance declaration for (Functor ((,) Bool))
In the expression: fmap not (True, True)
In the definition of `it': it = fmap not (True, True)
Prelude> :m +Data.Array
Prelude Data.Array> :i Functor
class Functor f where fmap :: (a -> b) -> f a -> f b
-- Defined in GHC.Base
instance (Ix i) => Functor (Array i) -- Defined in GHC.Arr
instance Functor ((->) r) -- Defined in Control.Monad.Instances
instance Functor ((,) a) -- Defined in Control.Monad.Instances
instance Functor (Either a) -- Defined in Control.Monad.Instances
instance Functor Maybe -- Defined in Data.Maybe
instance Functor [] -- Defined in GHC.Base
instance Functor IO -- Defined in GHC.IOBase
Prelude Data.Array> fmap not (True,True)
(True,False)
Prelude Data.Array> :m -Data.Array
Prelude> :i Functor
class Functor f where fmap :: (a -> b) -> f a -> f b
-- Defined in GHC.Base
instance Functor ((->) r) -- Defined in Control.Monad.Instances
instance Functor ((,) a) -- Defined in Control.Monad.Instances
instance Functor (Either a) -- Defined in Control.Monad.Instances
instance Functor Maybe -- Defined in Data.Maybe
instance Functor [] -- Defined in GHC.Base
instance Functor IO -- Defined in GHC.IOBase
Prelude> fmap not (True,True)
(True,False)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/2182#changelog
http://ghc.haskell.org/trac/ghc/ticket/2356
http://ghc.haskell.org/trac/ghc/ticket/2356#2356: GHC accepts multiple instances for the same type in different modulesTue, 10 Jun 2008 12:25:27 GMTclaus<p>
as mentioned by Simon PJ in this thread:
</p>
<p>
<a class="ext-link" href="http://www.haskell.org/pipermail/haskell/2008-June/020436.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell/2008-June/020436.html</a>
</p>
<p>
here is the example, spelled out:
</p>
<pre class="wiki">module B0 where
class C a where c :: a -> String
data T = T deriving Show
module B1 where
import B0
instance C T where c _ = "B1"
b = c T
module B2 where
import B0
instance C T where c _ = "B2"
b = c T
module Main where
import B1
import B2
main = print (B1.b,B2.b)
</pre><p>
this is accepted without flags or errors and prints <tt>("B1","B2")</tt>.
</p>
<p>
the <a class="ext-link" href="http://haskell.org/onlinereport/decls.html#sect4.3.2"><span class="icon"></span>language report, section 4.3.2</a> clearly states:
</p>
<blockquote>
<p>
A type may not be declared as an instance of a particular class more than once in the program.
</p>
</blockquote>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2356#changelog
http://ghc.haskell.org/trac/ghc/ticket/2401
http://ghc.haskell.org/trac/ghc/ticket/2401#2401: aborting an STM transaction should throw an exceptionSat, 28 Jun 2008 22:44:52 GMTsclv<p>
The attached test case will hang at +RTS -N2 and above. As noted in the other ticket I submitted (<a class="ext-link" href="http://hackage.haskell.org/trac/ghc/ticket/2398"><span class="icon"></span>http://hackage.haskell.org/trac/ghc/ticket/2398</a>), this behavior happens on an Core 2 Quad with 64 bit architecture, and does not take place on a PowerPC with 32 bit architecture and no multicore.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2401#changelog
http://ghc.haskell.org/trac/ghc/ticket/2465
http://ghc.haskell.org/trac/ghc/ticket/2465#2465: View + Pattern Match not fused sufficientlyThu, 24 Jul 2008 20:58:32 GMTryani<p>
This came up while playing with the ICFP2007 task.
</p>
<p>
I have a function <tt>dnaView :: DNA -> [D]</tt>; DNA is a <tt>[ByteString]</tt> and D is just the enum <tt>I|C|F|P</tt>. When I call a function that just pattern matches on the result, I think the pattern matching function should be fused with the view -- the view should run as a coroutine.
</p>
<p>
I've attached an example.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2465#changelog
http://ghc.haskell.org/trac/ghc/ticket/2625
http://ghc.haskell.org/trac/ghc/ticket/2625#2625: Unexpected -ddump-simpl output for derived Ord instance and UNPACKed fieldsWed, 24 Sep 2008 04:58:05 GMTaslatter<p>
In the following example, with either -O or -O2
</p>
<p>
In the derived Eq instance for A, in '==' nothing ever gets re-packed into a B constructor.
</p>
<p>
However in the derived Ord instance, in the 'compile' function the code from -ddump-simpl shows that the RHS of 'compare' is unpacked from the 'A' constructor only to be repacked in 'B' constructor and then passed on to a different function.
</p>
<p>
Is there any way we can do for 'compare' what was done for '==' ?
</p>
<p>
Thanks
</p>
<pre class="wiki">
module Bug where
data A = A {-# UNPACK #-} !B
deriving (Eq, Ord)
data B = B {-# UNPACK #-} !Int
{-# UNPACK #-} !Int
{-# UNPACK #-} !Int
{-# UNPACK #-} !Int
{-# UNPACK #-} !Int
{-# UNPACK #-} !Int
{-# UNPACK #-} !Int
deriving (Eq, Ord)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/2625#changelog