GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?status=closed&resolution=wontfix&order=id
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/query?status=closed&resolution=wontfix&order=id
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/68
http://ghc.haskell.org/trac/ghc/ticket/68#68: Warnings for unitialized fieldsWed, 24 Apr 2002 19:53:34 GMTnobody<p>
Would it be possible to add flag to disable warnings for
unitialized fields just when using constructor with
zero fields? I mean, if I use
</p>
<pre class="wiki"> Foo {}
</pre><p>
to construct empty record, it is a bit unpleasant that
I get flooded by dozens of useless warnings; but I don't
want to disable them -- they are useful when I forget
to initialize some field(s).
</p>
<p>
Zdenek Dvorak
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/68#changelog
http://ghc.haskell.org/trac/ghc/ticket/110
http://ghc.haskell.org/trac/ghc/ticket/110#110: Cygwin binariesWed, 15 Jan 2003 04:46:10 GMTfizzgig<pre class="wiki">A complete set of binaries for ghc and ghci under
cygwin would be really nice.
Using the win32-version works, but is far from satisfying.
GHCI does not recognize the arrow keys, thus no
command history (annoying errors instead) and I've
heard others complain about problem with linking, since
win32-ghc uses it's own gcc.
I tried to compile ghc myself, but gave up after a few
hours.
Please compile it and include it in cygwin's auto-update
system.
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/110#changelog
http://ghc.haskell.org/trac/ghc/ticket/315
http://ghc.haskell.org/trac/ghc/ticket/315#315: Arbitrary function sectionsThu, 03 Mar 2005 14:36:39 GMTa0s<pre class="wiki">For operators we have the following shorthand:
op :: a -> b -> c
(`op` y) === \x -> x `op` y
(x `op`) === \y -> x `op` y
It would be nice to have a similar facility for
functions, e.g.:
f :: a -> b -> c -> d -> e
f _ y _ t === \x z -> f x y z t
f x _ z _ === \y t -> f x y z t
f x _ z === \y -> f x y z === \y t -> f x y z t
Because "_" is currently not allowed as an identifier
in contexts where this facility could possibly be in
effect, it seems safe to use it to indicate omitted
parameters in function application.
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/315#changelog
http://ghc.haskell.org/trac/ghc/ticket/368
http://ghc.haskell.org/trac/ghc/ticket/368#368: Provide a Java BackendThu, 28 Apr 2005 12:20:57 GMTrainbowang<pre class="wiki">I hope the GHC provide a JVM backend.
also:
1. GHC compile hs to bytecode(name as klass) like what
javac
and klass can be packed as kjar(like jar in java)
2. an KVM interpret the klass bytecode and translate it
to java .class, then execute it on JVM. the KVM can be
write in haskell also.
now, a pure java based GHC and KVM can be used on JVM like
1. ghc.kjar contains the ghc compiler
2. happy.kjar contains the happy compiler
3. kvm.kjar contains the KVM
4. kvm.jar contains the bootstrap kvm that can be run
on JVM.
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/368#changelog
http://ghc.haskell.org/trac/ghc/ticket/420
http://ghc.haskell.org/trac/ghc/ticket/420#420: O'HaskellSat, 16 Jul 2005 14:42:39 GMTmlbm<pre class="wiki">
Is there any project for extending GHC with support to
O'Haskell or any other object-oriented Haskell
extesion? That could be very useful for improving
Haskell interoperability with OO languages.
Thanks in advance,
Monique Monteiro
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/420#changelog
http://ghc.haskell.org/trac/ghc/ticket/449
http://ghc.haskell.org/trac/ghc/ticket/449#449: Very big integer arithmetic crashes GHCi on Windows and MacThu, 01 Sep 2005 08:12:12 GMTsimonpj<pre class="wiki">With GHC 6.4, interpreted or compiled, on Windows and
Mac OS X,
evaluating the expression (4^(4^44))::Integer causes a
crash.
On Unix, it just goes out to lunch and eats memory,
which seems more plausible.
On Mac, the message is:
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.4, for
Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base-1.0 ... linking ... done.
Prelude> 4^(4^44)::Integer
bash: [539: 1] tcsetattr: Operation not supported
Segmentation fault
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/449#changelog
http://ghc.haskell.org/trac/ghc/ticket/451
http://ghc.haskell.org/trac/ghc/ticket/451#451: GHC poor type-checker error messageSun, 04 Sep 2005 13:23:52 GMTisaacdupree<pre class="wiki">Here is a very tricky GHC (6.4) error message I found.
I have simplified the context from where I found it,
but the error is basically the same (still rather less
confusing than the real thing, where Value ::
[TString], TString :: [(String,Textdomain)], and error
messages talked about, e.g., [[([Char],Textdomain)]]
instead of [[Char]]). I had to run the original through
Hugs to find my mistake there. Here is the code:
> import Data.List(intersperse)
> type Value = String
> -- unifyEnd :: [key] -> [Value] -> [Value]
> -- this example assumes (length ks <= length vs)
> unifyEnd ks vs =
> let (fvs,evs) = splitAt (length ks - 1) vs
> in fvs ++ concat (intersperse "," evs)
Here is the GHC-6.4 error message:
BadErrorMessage.lhs:10:41:
Couldn't match `[Char]' against `Char'
Expected type: [[Char]]
Inferred type: [Char]
In the second argument of `intersperse', namely `evs'
In the first argument of `concat', namely
`(intersperse "," evs)'
The error message when the type signature is
uncommented at least might lead to less pursuing of the
wrong things, claiming the literal `","' is in error
instead, but does not get to the location of the error.
The Hugs error, while not perfect, has got the location
correct: it shows me the part I erred in:
ERROR "BadErrorMessage.lhs":8 - Type error in application
*** Expression : fvs ++ concat (intersperse "," evs)
*** Term : fvs
*** Type : [[Char]]
*** Does not match : [Char]
I had forgotten to put [ ] around concat (...), i.e.
fvs ++ [concat (intersperse "," evs)]
is the corrected fragment of the definition.
GHC did not appear to realize that the two arguments to
'intersperse' were currently consistent with each
other, given intersperse's type signature of a -> [a]
-> [a], but would not be if the type of the one claimed
to be in error were changed to the "expected" type. (If
it could say that they were both the wrong type, that
would be another choice it had that makes sense, but
that would be two human errors, perhaps less likely
than one.)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/451#changelog
http://ghc.haskell.org/trac/ghc/ticket/482
http://ghc.haskell.org/trac/ghc/ticket/482#482: 'Bug' when installing GHC 6.4.1Tue, 22 Nov 2005 14:35:21 GMTnobody<p>
I installed GHC-6.4.1.pkg.zip under MacOSX, and selected
the startup volume for install. The idea is that
he puts the ghc exec. and the rest in /usr/local.
In my case, /usr/local/ is a symbolic link to another
partition.
It turns out that the installer then removes this link,
makes a new subdir /usr/local/ and installs
ghc in there. This means, all my other stuff has become
inaccessible. My feeling is that this is a bug.
I can imagine that you check whether /usr/local exists
and whether it is a directory, and maybe the case
that it is a symbolic link to a directory is not
yet covered.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/482#changelog
http://ghc.haskell.org/trac/ghc/ticket/485
http://ghc.haskell.org/trac/ghc/ticket/485#485: AdjustorAsm.S doesn't build on AIXWed, 23 Nov 2005 17:09:23 GMTjgoerzen<p>
OK, this is a weird one.
</p>
<p>
I'm building GHC 6.4.1 on AIX and using IBM's
assembler, since GNU binutils is known to have issues
on AIX.
</p>
<p>
When the build reached AdjustorAsm.S, I got:
</p>
<pre class="wiki">imer.h -#include ProfHeap.h -#include LdvProfile.h
-#include Profiling.h -#inclu
de Apply.h -fvia-C -dcmm-lint -c AdjustorAsm.S -o
AdjustorAsm.o
Assembler:
/tmp//ccq7dlbU.s: line 15: 1252-016 The specified
opcode or pseudo-op is not val
id.
Use supported instructions or pseudo-ops only.
/tmp//ccq7dlbU.s: line 48: 1252-149 Instruction subf is
not implemented in the c
urrent assembly mode COM.
/tmp//ccq7dlbU.s: line 52: 1252-142 Syntax error.
/tmp//ccq7dlbU.s: line 53: 1252-142 Syntax error.
/tmp//ccq7dlbU.s: line 58: 1252-142 Syntax error.
/tmp//ccq7dlbU.s: line 59: 1252-142 Syntax error.
make[2]: *** [AdjustorAsm.o] Error 1
</pre><p>
After some research, I added -opta -Wa,-mppc, which
reduced the errors to:
</p>
<pre class="wiki">/tmp//ccA1yNhC.s: line 15: 1252-016 The specified
opcode or pseudo-op is not val
id.
Use supported instructions or pseudo-ops only.
/tmp//ccA1yNhC.s: line 52: 1252-142 Syntax error.
/tmp//ccA1yNhC.s: line 53: 1252-142 Syntax error.
/tmp//ccA1yNhC.s: line 58: 1252-142 Syntax error.
/tmp//ccA1yNhC.s: line 59: 1252-142 Syntax error.
</pre><p>
I examined the temp files and found that line 15
contains only the word ".text".
</p>
<p>
I was finally able to work around the problem by adding
-opta -save-temps to the command line, then using GNU
as like so:
</p>
<p>
as mppc -I. AdjustorAsm.s -o AdjustorAsm.o
</p>
<p>
I then copied the resulting .o file to the thr, p,
debug, etc. .o files. The build was then able to complete.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/485#changelog
http://ghc.haskell.org/trac/ghc/ticket/551
http://ghc.haskell.org/trac/ghc/ticket/551#551: "No threads to run" ignores finalizersSun, 03 Jun 2001 05:21:38 GMTchak<pre class="wiki">This is re my posting under the subject "Weak pointers,
garbage collection & deadlocks" on
glasgow-haskell-users.
Basically, the problem is that finaliser threads that
the next GC would generate aren't taken into account
when determining whether there are any more threads to
run.
I attach a program reproducing the error.
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/551#changelog
http://ghc.haskell.org/trac/ghc/ticket/566
http://ghc.haskell.org/trac/ghc/ticket/566#566: mips-sgi-irix6.5 port?Sun, 15 Jul 2001 22:11:29 GMTduncan_coutts<pre class="wiki">How difficult would a mips-sgi-irix6.5 port be?
the ghc pages say:
mips-sgi-irix5:
Port currently doesn't work, needs some minimal
porting effort. As usual, we don't have
access to machines and there hasn't been an
overwhelming demand for this port, but feel
free to get in touch.
How much skill / experience would be necessary for such
a port?
Ie. I'm wondering if I could do it.
ta for any advice
Duncan
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/566#changelog
http://ghc.haskell.org/trac/ghc/ticket/598
http://ghc.haskell.org/trac/ghc/ticket/598#598: GHC DebuggerWed, 12 May 2004 00:00:00 GMTsimonmar<p>
We have a prototype debugger (<tt>ghc/utils/hsdebug</tt> on the <tt>speceval_2</tt> branch). This could be made to work for the ordinary (non-speceval) compiler and enhanced in lots of interesting ways to provide basic debugging support for GHC-compiled programs.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/598#changelog
http://ghc.haskell.org/trac/ghc/ticket/615
http://ghc.haskell.org/trac/ghc/ticket/615#615: Remove uses of ccall from PackedStringSat, 05 May 2001 00:00:00 GMTsimonmar<pre class="wiki">PackedString still uses ccall which is deprecated. It should use the new FFI libraries instead.
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/615#changelog
http://ghc.haskell.org/trac/ghc/ticket/619
http://ghc.haskell.org/trac/ghc/ticket/619#619: Port Hugs's Windows front end to GHCi.Sat, 05 May 2001 00:00:00 GMTsimonmar<p>
Port Hugs's Windows front end to GHCi.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/619#changelog
http://ghc.haskell.org/trac/ghc/ticket/667
http://ghc.haskell.org/trac/ghc/ticket/667#667: Efficient Map <-> Set conversionsMon, 23 Jan 2006 10:04:08 GMTjpbernardy<p>
We should be able to convert a Set into a Map without re-computation of the tree Shape. (initially proposed by John Meacham)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/667#changelog
http://ghc.haskell.org/trac/ghc/ticket/668
http://ghc.haskell.org/trac/ghc/ticket/668#668: Compiler loops indefinitely on Morris-style fixed-point operatorTue, 24 Jan 2006 14:43:58 GMTStefan Holdermans (stefan@…<p>
Consider the following programs:
</p>
<pre class="wiki">-- program 1.hs
newtype F a = F {unF :: F a -> a}
fix f = (\x -> f (unF x x)) (F (\x -> f (unF x x)))
fac = fix (\f -> \n -> if n == 0 then 1 else n * f (n - 1))
main = return ()
</pre><pre class="wiki">-- program 2: morris2.hs
newtype F a = F {unF :: F a -> a}
fix f = (\x -> f (unF x x)) (F (\x -> f (unF x x)))
fac = fix (\f -> \n -> if n == 0 then 1 else n * f (n - 1))
main = print (fac 2)
</pre><p>
The first one compiles just fine; the second however causes GHC to go in an infinite loop:
</p>
<pre class="wiki">$ ghc -c morris1.hs
$
</pre><pre class="wiki">$ ghc -c morris2.hs
(loops)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/668#changelog
http://ghc.haskell.org/trac/ghc/ticket/670
http://ghc.haskell.org/trac/ghc/ticket/670#670: External Core is brokenWed, 25 Jan 2006 07:49:12 GMTKirstenChevalier<pre class="wiki">$ ghc -fext-core Main.hs
$ ghc -fglasgow-exts Main.hcr
ghc-6.5: panic! (the `impossible' happened, GHC version 6.5):
tcIfaceGlobal (local): not found:
Main.main{v rrl}
[]
Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
</pre><p>
Main.hs consists of:
<tt> main = putStr "Hello world!" </tt>
</p>
<p>
I'll fix this myself if I still have commit access; I just want to have a record of it.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/670#changelog
http://ghc.haskell.org/trac/ghc/ticket/671
http://ghc.haskell.org/trac/ghc/ticket/671#671: GHC can suggest "Probable fixes" that are impossibleWed, 25 Jan 2006 14:23:45 GMTglasser@…<p>
Let's say I type in ["foo", 4] to GHCI:
</p>
<p>
Prelude> ["foo", 4]
</p>
<p>
<interactive>:1:8:
</p>
<blockquote>
<p>
No instance for (Num [Char])
</p>
<blockquote>
<p>
arising from the literal `4' at <interactive>:1:8
</p>
</blockquote>
<p>
Probable fix: add an instance declaration for (Num [Char])
In the list element: 4
In the definition of `it': it = ["foo", 4]
</p>
</blockquote>
<p>
It suggests a "Probable fix": add an instance declaration for (Num [Char]). OK, great. However, as soon as I try to evaluate "instance Num [Char] where" I get
</p>
<blockquote>
<p>
Illegal instance declaration for `Num [Char]'
</p>
<blockquote>
<p>
(The instance type must be of form (T a b c)
</p>
<blockquote>
<p>
where T is not a synonym, and a,b,c are distinct type variables)
</p>
</blockquote>
</blockquote>
<p>
In the instance declaration for `Num [Char]'
</p>
</blockquote>
<p>
Now, I'm not enough of an expert on the type class system to know if this means that it's absolutely impossible to declare instances on [Char], but it certainly seems like that. Thus, the "Probable fix" is in error, since [Char] can't get a Num instance. (Though I guess (Num a) => [a] can, so maybe this whole issue is a little moot.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/671#changelog
http://ghc.haskell.org/trac/ghc/ticket/674
http://ghc.haskell.org/trac/ghc/ticket/674#674: Bad error message: varying argumentsSat, 28 Jan 2006 09:21:09 GMTguest<p>
A function definition like
</p>
<pre class="wiki">f :: Maybe () -> Char
f Nothing = 'a'
f Just () = 'b'
</pre><p>
yields the error message
</p>
<blockquote>
<p>
Varying number of arguments for function `f'
</p>
</blockquote>
<p>
under 6.4.1 (pointing to the line with Nothing as containing the error). The following error message would be easier to understand for beginners (pointing to the line with Just):
</p>
<blockquote>
<p>
The type signature for f specifies that the function should take one argument, but you have given it two arguments.
</p>
</blockquote>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/674#changelog
http://ghc.haskell.org/trac/ghc/ticket/690
http://ghc.haskell.org/trac/ghc/ticket/690#690: Accept source files in encodings other than UTF-8Fri, 10 Feb 2006 12:49:31 GMTsimonmar<p>
We need to support at least Latin-1, for backwards compatibility.
</p>
<p>
One possibility is to run iconv as a preprocessor. Alternatively, call iconv directly from the compiler. What about Windows? Should there be a pragma specifying encoding, or take it from the locale, or a command-line flag, or all three?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/690#changelog
http://ghc.haskell.org/trac/ghc/ticket/720
http://ghc.haskell.org/trac/ghc/ticket/720#720: Map/Set range functionFri, 10 Mar 2006 20:38:21 GMTjpbernardy<p>
Data.Map seems to lack a way to perform range queries
like "fetch all elements between keys low and high".
The naive implementation is easy:
</p>
<pre class="wiki">range :: Ord k => k -> k -> Map.Map k v -> [(k,v)]
range low high = toList . fst . split high . snd . split low
</pre><p>
But this is not very fast for larger maps. Maybe
this operation could be provided in Data.Map?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/720#changelog
http://ghc.haskell.org/trac/ghc/ticket/721
http://ghc.haskell.org/trac/ghc/ticket/721#721: Write Data.TrieFri, 10 Mar 2006 20:51:25 GMTjpbernardy<p>
Pull the various Trie implementations that lie around, and make something that has (roughly) the same interface as Data.Map, but for lists as keys.
</p>
<p>
See this thread on the libraries mailing list.
<a class="ext-link" href="http://www.haskell.org//pipermail/libraries/2005-February/003217.html"><span class="icon"></span>http://www.haskell.org//pipermail/libraries/2005-February/003217.html</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/721#changelog
http://ghc.haskell.org/trac/ghc/ticket/722
http://ghc.haskell.org/trac/ghc/ticket/722#722: Adrian Hey's StringMap library in the collections package.Fri, 10 Mar 2006 21:09:54 GMTjpbernardy<ul><li>Bring Adrian Hey's StringMap to a higher level of completeness, so it can be made an instance of the Map class.
</li></ul><ul><li>Add an abstraction layer, as close a possible to Data.Map, so it can be a drop-in replacement in most cases.
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/722#changelog
http://ghc.haskell.org/trac/ghc/ticket/731
http://ghc.haskell.org/trac/ghc/ticket/731#731: GHCi doesn't work on powerpc64Tue, 21 Mar 2006 15:30:02 GMTsimonmar<p>
See diagnosis from Duncan Coutts:
</p>
<blockquote>
<p>
<a class="ext-link" href="http://www.haskell.org//pipermail/cvs-ghc/2006-March/028889.html"><span class="icon"></span>http://www.haskell.org//pipermail/cvs-ghc/2006-March/028889.html</a>
</p>
</blockquote>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/731#changelog
http://ghc.haskell.org/trac/ghc/ticket/740
http://ghc.haskell.org/trac/ghc/ticket/740#740: Copyright information is wrong in some GHC source filesFri, 07 Apr 2006 18:33:49 GMTguest<p>
I noticed with some amusement that the copyright in some
of the GHC library files is wrong. It claims the copyright
belongs to the University of Glasgow, but it doesn't
(at least not for all the code).
I know, because I wrote the original code. And copyright law
states that the author holds the copyright even if the work does
not contain a copyright notice.
An example of such a file is libraries/base/GHC/Float.lhs.
</p>
<p>
I don't really care if this is fixed our not; I'm happy to share
the code, but a line of attribution doesn't seem like an outrageous
request.
</p>
<blockquote>
<p>
-- Lennart
</p>
</blockquote>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/740#changelog
http://ghc.haskell.org/trac/ghc/ticket/785
http://ghc.haskell.org/trac/ghc/ticket/785#785: Allow partial application of type synonymsSun, 04 Jun 2006 16:13:22 GMTBulat.Ziganshin@…<p>
the enclosed program shows what i need. in particular, it is useful for arrays library, which widely uses higher-kind type constructors and classes around them
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/785#changelog
http://ghc.haskell.org/trac/ghc/ticket/835
http://ghc.haskell.org/trac/ghc/ticket/835#835: Expose less type/class info in an interface file, to reduce recompilationThu, 27 Jul 2006 08:30:45 GMTsimonpj<p>
John Meacham writes "However, whenever I change a data type or class even if they are not exported, it seems to force a full rebuild of everything that depends on that file. Is there any fundamental reason this can't be fixed? why do the non exported classes and data types end up in the hi file anyway (assuming they appear in no exported functions type signature of course)."
</p>
<p>
Solution: Fix GHC so that it doesn't expose a data type at all if nothing about it is exported; and doesn't its constructors if they are not exported, and not used in any unfolding.
</p>
<p>
Doing this would reduce recompilation changes.
</p>
<p>
<a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-users/2006-July/010596.html"><span class="icon"></span>http://www.haskell.org/pipermail/glasgow-haskell-users/2006-July/010596.html</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/835#changelog
http://ghc.haskell.org/trac/ghc/ticket/837
http://ghc.haskell.org/trac/ghc/ticket/837#837: Infer fully qualified names to overcome namespace clashesFri, 28 Jul 2006 03:23:42 GMTp.tanski@…<p>
If you could interpret Section 5.5.2 of the last published Haskell Report (1998) as meaning: "[i]t is not an error for there to exist names [such as A.f or f] that cannot be ... resolved [by the implementation] ..." Then it would be exceptionally handy for GHC to be able to infer what any human being can infer from most name usage in a function. For example:
</p>
<p>
import Data.Map
import Data.List
</p>
<p>
runThroughMap :: (Ord k) => Map k a -> Map k b
runThroughMap m = map f m
</p>
<p>
runThroughList :: [a] -> [b]
runThroughList l = map g l
</p>
<p>
GHC will produce an error that this "map" is an ambiguous reference and provides a nice error message containing the fully qualified names. If you accept a permissive interpretation of Section 5.5.2 of the '98 Report, GHC could infer from context that map in <tt>runThroughMap</tt> is being used on a Map and therefore should be fully qualifiable and unambiguous; similarly for map used in <tt>runThroughList.</tt>
</p>
<p>
Of course, if you disagree with this interpretation for whatever reason--many reasons are practical--feel free to delete this feature request...
</p>
<p>
W.B.R.
</p>
<blockquote>
<p>
-Peter T.
</p>
</blockquote>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/837#changelog
http://ghc.haskell.org/trac/ghc/ticket/851
http://ghc.haskell.org/trac/ghc/ticket/851#851: Incomplete-pattern checking for n+k patterns is not implementedTue, 08 Aug 2006 14:51:35 GMTsimonpj<p>
The check for incomplete patterns does not understand about n+k patterns. Here's an example:
</p>
<pre class="wiki">f 0 = True
f (n+1) = False
</pre><p>
GHC says, rather confusingly:
</p>
<pre class="wiki"> Warning: Pattern match(es) are non-exhaustive
In the definition of `f':
Patterns not matched: #x with #x `notElem` [0#]
</pre><p>
The reason is in <tt>compiler/deSugar/Check.hs</tt> which says
</p>
<pre class="wiki"> -- Horrible hack. The simplify_pat stuff converts NPlusK pats to WildPats
-- which of course loses the info that they can fail to match. So we
-- stick in a CanFail as if it were a guard.
-- The Right Thing to do is for the whole system to treat NPlusK pats properly
</pre><p>
See <a class="new ticket" href="http://ghc.haskell.org/trac/ghc/ticket/595" title="task: Overhaul GHC's overlapping/non-exhaustive pattern checking (new)">ticket:595</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/851#changelog
http://ghc.haskell.org/trac/ghc/ticket/907
http://ghc.haskell.org/trac/ghc/ticket/907#907: Case sensitive ghci commandsSun, 24 Sep 2006 01:19:36 GMTbr1@…<p>
In spanish keyboards you have to use the shift key to get a colon (:). This bites me when I do ":r" in ghci. Half the time I get ":R". I would like to request that case made no difference in this case.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/907#changelog
http://ghc.haskell.org/trac/ghc/ticket/913
http://ghc.haskell.org/trac/ghc/ticket/913#913: instance Ord (StableName a)Thu, 28 Sep 2006 09:19:13 GMTekarttun<p>
Being able to have an Ord instance for StableNames would make sense. This would be very useful for code passing around a Set of StableNames. As the Eq instance already exists this would probably not involve any new issues.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/913#changelog
http://ghc.haskell.org/trac/ghc/ticket/927
http://ghc.haskell.org/trac/ghc/ticket/927#927: Type checker infers () instead of aSat, 07 Oct 2006 22:39:48 GMTguest<p>
A small module loaded into ghci -fglasgow-exts 6.4.1:
</p>
<pre class="wiki">module M where
class C a b | a -> b where
same :: a -> b
instance C () ()
instance C a b => C (c -> a) (c -> b)
foo = same (const ())
Asking :i foo yields
foo :: () -> ()
</pre><p>
I would expect <tt>a -> ()</tt> -- what gives?
</p>
<p>
John Hughes
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/927#changelog
http://ghc.haskell.org/trac/ghc/ticket/944
http://ghc.haskell.org/trac/ghc/ticket/944#944: OPTIONS_GHC in included file ignored sometimesSun, 15 Oct 2006 15:16:48 GMTgreenrd<p>
In the attached test case, the OPTIONS_GHC pragma is ignored in the included header file. However, the problem goes away if you use --make, surprisingly. Unfortunately, in my real code, the problem does not go away when I use --make.
</p>
<p>
I'd argue that this (putting OPTIONS_GHC in a #include file) should work, because
</p>
<p>
(a) It worked with ghc 6.4.2
</p>
<p>
(b) It's useful to centralise options in one place
</p>
<p>
(c) Logically, if the first line of the #included file is the OPTIONS_GHC pragma, and the #include line is on the first line of the .hs file, the OPTIONS_GHC should appear to ghc to be in the right place.
</p>
<p>
Compile this test case with: ghc -cpp test.hs
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/944#changelog
http://ghc.haskell.org/trac/ghc/ticket/951
http://ghc.haskell.org/trac/ghc/ticket/951#951: stage2 on sparc dies with "schedule: re-entered unsafely"Wed, 18 Oct 2006 10:26:03 GMTduncan<p>
Building a registerised GHC-6.6 on Sparc Solaris or Sparc Linux gives a stage2 with the following problem:
</p>
<pre class="wiki">$ ghc --version
ghc-6.6: schedule: re-entered unsafely.
Perhaps a 'foreign import unsafe' should be 'safe'?
</pre><p>
This happens for Christian Maeder on Solaris and for me on Linux. It does not seem to be related to <tt>SPLIT_OBJS=</tt> in the <tt>mk/build.mk</tt>.
</p>
<p>
Christian reports that it works for him with gcc-4.0.3 but not gcc-3.4.4, though that was not the only thing different between the two configurations:
</p>
<pre class="wiki">It works with gcc_4.0.3_s10 on
"SunOS leo 5.10 Generic_118833-20 sun4u sparc SUNW,Sun-Fire-280R"
It crashes as above on
"SunOS cni 5.10 Generic_118833-24 sun4u sparc SUNW,Sun-Fire-V240"
with gcc_3.4.4_s10.
</pre><p>
My results do not contradict this as I am using gcc-3.4.6 on Sparc Linux.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/951#changelog
http://ghc.haskell.org/trac/ghc/ticket/992
http://ghc.haskell.org/trac/ghc/ticket/992#992: Database supportTue, 07 Nov 2006 14:22:49 GMTdemius_md@…<p>
How about include some database lib into packages?
Thank you
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/992#changelog
http://ghc.haskell.org/trac/ghc/ticket/996
http://ghc.haskell.org/trac/ghc/ticket/996#996: Add ranged setsFri, 10 Nov 2006 20:10:38 GMTpauljohnson<p>
Ranged sets represent sets of ordered values as lists of ranges. Each range has a lower and
upper boundary, and for any value and boundary the value is either above or below the boundary:
no value can ever sit on a boundary. There are also boundaries for +/- infinity (BoundaryBelowAll and BoundaryAboveAll).
</p>
<p>
The upshot is that you can represent a set of reals such as
</p>
<blockquote>
<p>
[ 2.0 < x <= 3.4, 6.7 < x]
</p>
</blockquote>
<p>
or a couple of encyclopedia volumes as:
</p>
<blockquote>
<p>
<a class="missing wiki"><= x < "blob", "goo" <= x < "hun"?</a>
</p>
</blockquote>
<p>
The usual set operators are provided. The library also does the Right Thing with adjacent values:
</p>
<blockquote>
<p>
[2 < x <= 3] Union [4 <= x < 5] == [2 < x < 5]
</p>
</blockquote>
<blockquote>
<p>
[2.0 < x <= 3.0] Union [4.0 <= x < 5.0] == [2.0 < x <= 3.0, 4.0 <= x < 5.0]
</p>
</blockquote>
<p>
I've needed something like this more than once over the years, in various languages. Haskell
is the first one that can actually do the Right Thing efficiently for a polymorphic type.
</p>
<p>
The source contains Haddock comments and a comprehensive set of QuickCheck properties. I've integrated these into the documentation. So far I've tested this on GHC 6.4.1, although this patch is against the HEAD of the current libraries.
</p>
<p>
If this patch is accepted I'll also add patches for ranged sets of times (e.g. the set of all times within the first Tuesday of each month), and to filter finite maps against ranged sets.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/996#changelog
http://ghc.haskell.org/trac/ghc/ticket/1005
http://ghc.haskell.org/trac/ghc/ticket/1005#1005: Add Logical Shift OperatorsThu, 16 Nov 2006 06:50:13 GMTrob@…<p>
This patch adds logical shift operators to complement the current arithmetic shift operators in Data.Bits.
</p>
<p>
The patch has been tested against GHC on Linux running on Intel 32bit architecture. I haven't had an opportunity to test other architectures but they should work fine.
</p>
<p>
The patch shouldn't break NHC or Hugs but I haven't been able to test them either. As it currently is, among the Int family, logical shift operators should work on these platforms for Int only. the Int* family of sized integers will currently treat logical shift operators as arithmetic shift operators as I couldn't figure out how to patch these.
</p>
<p>
Integer will raise an error if a logical right-shift operator is attempted since it doesn't seem to make any sense for this type.
</p>
<p>
By default, the logical shift operators will act as arithmetic shift operators and so should require no method definition for unsigned types.
</p>
<p>
The patch also includes quickcheck properties which I've taken the liberty of creating a Tests directory for. I thought it would make sense to keep quickcheck properties with the library they belong to for easier management.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1005#changelog
http://ghc.haskell.org/trac/ghc/ticket/1022
http://ghc.haskell.org/trac/ghc/ticket/1022#1022: Add System.FilePath to baseWed, 22 Nov 2006 12:28:54 GMTguest<p>
Here is the proposal to add System.FilePath to base. The System.FilePath module is located at <a class="ext-link" href="http://www-users.cs.york.ac.uk/~ndm/projects/libraries.php#filepath"><span class="icon"></span>http://www-users.cs.york.ac.uk/~ndm/projects/libraries.php#filepath</a>
</p>
<p>
In particular I propose the addition of System.FilePath (a
cross-platform FilePath manipulation library), System.FilePath.Windows
(Windows paths on all OS's) and System.FilePath.Posix (Posix paths on
all OS's). The Version_* stuff is not being proposed for addition.
</p>
<p>
<a class="ext-link" href="http://article.gmane.org/gmane.comp.lang.haskell.libraries/5751"><span class="icon"></span>http://article.gmane.org/gmane.comp.lang.haskell.libraries/5751</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1022#changelog
http://ghc.haskell.org/trac/ghc/ticket/1032
http://ghc.haskell.org/trac/ghc/ticket/1032#1032: Test.QuickCheck.Batch overflow in length of testsWed, 29 Nov 2006 18:59:00 GMTgwright@…<p>
This problem was originally reported as bug <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1004" title="bug: ghci-6.6 crash (closed: invalid)">#1004</a>. There were
actually two issues, which are now bug <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1013" title="bug: interpretBCO: unknown or unimplemented opcode 64356 (closed: fixed)">#1013</a> and this one.
</p>
<p>
The following code fails (compiled and under ghci):
</p>
<pre class="wiki">{-# OPTIONS_GHC -fglasgow-exts #-}
--
-- Checksum.hs, support for checksumming data.
--
--module Checksum (
-- checksum
--) where
module Main where
import Utils
import Control.Exception
import Data.Array
import Data.Bits
import Data.List
import Data.Word
import Test.QuickCheck
import Test.QuickCheck.Batch
crcTable :: Array Word8 Word16
crcTable = listArray (0, 255)
[ 0x0000, 0x5935, 0xB26A, 0xEB5F, 0x3DE1, 0x64D4, 0x8F8B, 0xD6BE,
0x7BC2, 0x22F7, 0xC9A8, 0x909D, 0x4623, 0x1F16, 0xF449, 0xAD7C,
0xF784, 0xAEB1, 0x45EE, 0x1CDB, 0xCA65, 0x9350, 0x780F, 0x213A,
0x8C46, 0xD573, 0x3E2C, 0x6719, 0xB1A7, 0xE892, 0x03CD, 0x5AF8,
0xB63D, 0xEF08, 0x0457, 0x5D62, 0x8BDC, 0xD2E9, 0x39B6, 0x6083,
0xCDFF, 0x94CA, 0x7F95, 0x26A0, 0xF01E, 0xA92B, 0x4274, 0x1B41,
0x41B9, 0x188C, 0xF3D3, 0xAAE6, 0x7C58, 0x256D, 0xCE32, 0x9707,
0x3A7B, 0x634E, 0x8811, 0xD124, 0x079A, 0x5EAF, 0xB5F0, 0xECC5,
0x354F, 0x6C7A, 0x8725, 0xDE10, 0x08AE, 0x519B, 0xBAC4, 0xE3F1,
0x4E8D, 0x17B8, 0xFCE7, 0xA5D2, 0x736C, 0x2A59, 0xC106, 0x9833,
0xC2CB, 0x9BFE, 0x70A1, 0x2994, 0xFF2A, 0xA61F, 0x4D40, 0x1475,
0xB909, 0xE03C, 0x0B63, 0x5256, 0x84E8, 0xDDDD, 0x3682, 0x6FB7,
0x8372, 0xDA47, 0x3118, 0x682D, 0xBE93, 0xE7A6, 0x0CF9, 0x55CC,
0xF8B0, 0xA185, 0x4ADA, 0x13EF, 0xC551, 0x9C64, 0x773B, 0x2E0E,
0x74F6, 0x2DC3, 0xC69C, 0x9FA9, 0x4917, 0x1022, 0xFB7D, 0xA248,
0x0F34, 0x5601, 0xBD5E, 0xE46B, 0x32D5, 0x6BE0, 0x80BF, 0xD98A,
0x6A9E, 0x33AB, 0xD8F4, 0x81C1, 0x577F, 0x0E4A, 0xE515, 0xBC20,
0x115C, 0x4869, 0xA336, 0xFA03, 0x2CBD, 0x7588, 0x9ED7, 0xC7E2,
0x9D1A, 0xC42F, 0x2F70, 0x7645, 0xA0FB, 0xF9CE, 0x1291, 0x4BA4,
0xE6D8, 0xBFED, 0x54B2, 0x0D87, 0xDB39, 0x820C, 0x6953, 0x3066,
0xDCA3, 0x8596, 0x6EC9, 0x37FC, 0xE142, 0xB877, 0x5328, 0x0A1D,
0xA761, 0xFE54, 0x150B, 0x4C3E, 0x9A80, 0xC3B5, 0x28EA, 0x71DF,
0x2B27, 0x7212, 0x994D, 0xC078, 0x16C6, 0x4FF3, 0xA4AC, 0xFD99,
0x50E5, 0x09D0, 0xE28F, 0xBBBA, 0x6D04, 0x3431, 0xDF6E, 0x865B,
0x5FD1, 0x06E4, 0xEDBB, 0xB48E, 0x6230, 0x3B05, 0xD05A, 0x896F,
0x2413, 0x7D26, 0x9679, 0xCF4C, 0x19F2, 0x40C7, 0xAB98, 0xF2AD,
0xA855, 0xF160, 0x1A3F, 0x430A, 0x95B4, 0xCC81, 0x27DE, 0x7EEB,
0xD397, 0x8AA2, 0x61FD, 0x38C8, 0xEE76, 0xB743, 0x5C1C, 0x0529,
0xE9EC, 0xB0D9, 0x5B86, 0x02B3, 0xD40D, 0x8D38, 0x6667, 0x3F52,
0x922E, 0xCB1B, 0x2044, 0x7971, 0xAFCF, 0xF6FA, 0x1DA5, 0x4490,
0x1E68, 0x475D, 0xAC02, 0xF537, 0x2389, 0x7ABC, 0x91E3, 0xC8D6,
0x65AA, 0x3C9F, 0xD7C0, 0x8EF5, 0x584B, 0x017E, 0xEA21, 0xB314 ]
-- | Compute our standard checksum
--
checksum :: [Word8] -> Word16
checksum msg =
let
update :: Word16 -> Word8 -> Word16
update reg byte = (reg `shiftL` 8) `xor`
crcTable ! ((fromIntegral (reg `shiftR` 8)) `xor` byte)
in
foldl' update 0 msg
-- | Tests
--
instance Arbitrary Word8 where
arbitrary =
do n <- choose ((fromIntegral (minBound :: Word8)) :: Int,
(fromIntegral (maxBound :: Word8)) :: Int)
return (fromIntegral n)
coarbitrary v = variant 0 . coarbitrary v
prop_checksum xs = checksum (xs ++ splitWord (checksum xs)) == 0
where types = xs :: [Word8]
testOpts = TestOptions {no_of_tests = 1000,
length_of_tests = 3600,
debug_tests = True}
batch = do
result <- run prop_checksum testOpts
case result of
TestOk _ i _ -> putStrLn ("test ok: " ++ show i)
TestExausted _ i _ -> putStrLn ("test exhausted: " ++ show i)
TestFailed strs i -> putStrLn ("test failed: " ++ concat strs)
TestAborted ex -> putStrLn ("test aborted: " ++ show ex)
main = batch
</pre><p>
it fails under ghci with
</p>
<pre class="wiki">57:
[61,48,20]
58:
[80,90,202,253,203,52,183]
59:
[]
60:
[170,171,181,63,181,52,179,117]
61:
[56test aborted: <<loop>>
*Main>
</pre><p>
As noted by Thorkil (see <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1004" title="bug: ghci-6.6 crash (closed: invalid)">#1004</a>), the problem is in the length_of_tests field.
This field is an Int, and is converted to microseconds by Test.QuickCheck.Batch.run.
The conversion can overflow if length_of_tests is too large (a few thousand).
</p>
<p>
That this error is not detected is a bug. If the length_of_tests field is too
large, ghc should do one of: 1) terminate with an error; 2) throw an exception;
3) silently truncate to the maximum representable delay on the particular OS;
4) wrap around, setting the delay to the specified delay modulo the maximum
representable delay; or 5) do something better that someone else suggests.
</p>
<p>
If anyone has a good suggest, I will be happy to work up a patch based on it.
Otherwise, I'll pick one of 1) through 4).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1032#changelog
http://ghc.haskell.org/trac/ghc/ticket/1049
http://ghc.haskell.org/trac/ghc/ticket/1049#1049: A means of testing whether code is in blocked or unblocked modeWed, 13 Dec 2006 15:22:40 GMTChrisKuklewicz<p>
There is currently no way for code, e.g. in a library, to test whether it is running in a blocked or unblocked state. The only uses I have for this is to implement work arounds for the problem with throwTo & block (ticket 1047) or to write forkInheritIO in terms of forkIO and forkBlockedIO (from ticket 1048).
</p>
<p>
something like:
</p>
<p>
areExceptionsBlocked :: IO Bool -- True in scope of block, false in scope of unblock
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1049#changelog
http://ghc.haskell.org/trac/ghc/ticket/1058
http://ghc.haskell.org/trac/ghc/ticket/1058#1058: Highlight matching parantheses in Visual StudioMon, 18 Dec 2006 17:24:11 GMTm4dc4p<p>
I would like to see the "matching" parentheses highlighted when editing source code in Visual Studio and the text cursor is placed on a beginning or ending parentheses. It's not common to use parentheses in Haskell, but when you have to this feature is very nice to have.
</p>
<p>
Adding this capability to braces (i.e. "{", "}") and brackets ("<a class="missing wiki">,?</a>") would also be nice.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1058#changelog
http://ghc.haskell.org/trac/ghc/ticket/1064
http://ghc.haskell.org/trac/ghc/ticket/1064#1064: Allow users to add commentary to Haddock docsWed, 20 Dec 2006 09:52:12 GMTsimonpj<p>
It would be great if Haddock generated web pages that allowed <strong>users</strong> to add commentary to the documentation. That would make it much more interactive. The PHP manual does this, to good effect <a class="ext-link" href="http://blog.milkfarmsoft.com/?p=29"><span class="icon"></span>http://blog.milkfarmsoft.com/?p=29</a>
</p>
<p>
In fact, Haddock already supports something like this. It has a flag that adds a Wiki link to every function definition; users can click on the link to get to a Wiki page that they can then add material to. But it's not perfect:
</p>
<ul><li>Most of the Wiki links will be empty, but there's no way to tell that when looking at the link. It'd be better to highlight populated links somehow.
</li><li>The library author may want to look at all the comments for a module, with a view to enhancing the Haddock docs; but it would be unbearably tedious to go through them all one by one.
</li><li>There is no place for overall comments
</li></ul><p>
There is real potential here, but it needs someone to think about it, and implement something a bit better.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1064#changelog
http://ghc.haskell.org/trac/ghc/ticket/1066
http://ghc.haskell.org/trac/ghc/ticket/1066#1066: MacOSX powerpc gcc 3.3/4.0 and unknown symbol `_printf$LDBLStub'Thu, 21 Dec 2006 13:15:18 GMTgracjan-agh.edu.pl<p>
There are problems with linking on MacOSX 10.4.8 when selected gcc 3.3. Following session demonstrates problem:
</p>
<pre class="wiki">gracjan$ sudo gcc_select 3.3
Default compiler has been set to:
gcc version 3.3 20030304 (Apple Computer, Inc. build 1819)
gracjan$ ghc --make x.hs
[1 of 1] Compiling Main ( x.hs, x.o )
Linking x ...
ld: Undefined symbols:
_sprintf$LDBLStub
_fprintf$LDBLStub
_vfprintf$LDBLStub
gracjan$ sudo gcc_select 4.0
Default compiler has been set to:
gcc version 4.0.1 (Apple Computer, Inc. build 5363)
gracjan$ ghc --make x.hs
Linking x ...
gracjan$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.6
</pre><p>
Linking manually with <tt>-lSystemStubs</tt> fixes the problem. Seems to be connected with Ticket <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1018" title="bug: ghci dynamic loading of X11 - unknown symbol `_printf$LDBLStub' (closed: fixed)">#1018</a>, where the solution is to only add <tt>-lSystemStubs</tt> when build evironment says so. Probably adding it always could be a solution.
</p>
<p>
Affected: ghc-6.6-ppc-apple-darwin.tar.gz from <a class="ext-link" href="http://haskell.org/ghc/download_ghc_66.html"><span class="icon"></span>http://haskell.org/ghc/download_ghc_66.html</a>, also macports:
</p>
<pre class="wiki">gracjan$ port info ghc
ghc 6.6, Revision 2, lang/ghc (Variants: darwin_6, darwin_7_powerpc, darwin_8_powerpc, darwin_8_i386, noopengl)
http://www.haskell.org/ghc
Library Dependencies: readline, gmp
Runtime Dependencies: perl5.8
Platforms: darwin
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1066#changelog
http://ghc.haskell.org/trac/ghc/ticket/1078
http://ghc.haskell.org/trac/ghc/ticket/1078#1078: Using X11 through ffi on windows does not workMon, 01 Jan 2007 16:42:56 GMTAzmo<p>
When using the X11 Xlib through the ffi instead of using the existing binding
on linux it works fine. On windows it does not.
I have written similar programs, with the same result.
I have had no problems like this before.
</p>
<p>
I link with the "libX11-6" library, which comes with X11 for cygwin.
the "libX11-6" is the only choise. Can not find anything else to use.
This particular lib works fine if writing an equivalent program in C
and explicitly linking with it using GCC.
</p>
<p>
Strangely, if the argument to XOpenDisplay is wrong, the function actually
returns, and with a 0, which makes sense since it failed. Same result on
linux, but this is the only case where it actually works on windows.
If the argument is 0, then the function seems to correctly read the DISPLAY
environment variable, and then if that is invalid the function returns 0,
otherwise the program crashes/hangs.
</p>
<hr />
<p>
A program that uses ffi to access the X11 Xlib.
Works fine on linux, but on win2k + cygwin:
</p>
<ul><li>using:
<blockquote class="citation">
<p>
ghc --make no_c_test.hs -ffi -L"Y:\cygwin\usr\X11R6\lib" -llibX11-6 -fglasgow-exts
</p>
</blockquote>
when run, it crashes with: "The instruction at "0x00000000" referenced memory
at "0x00000000". The memory could not be "read".
</li></ul><ul><li>using:
<blockquote class="citation">
<p>
(same as above, but adding any of: -fvia-C -O -O2 )
</p>
</blockquote>
when run, it seems to go into an infinite loop after printing "before".
</li></ul><pre class="wiki">
import Foreign.C.String (withCString, CString)
import Foreign.Ptr (Ptr)
import Foreign.C.Types (CInt)
foreign import ccall safe "XOpenDisplay"
openDisplay :: CString -> IO (Ptr DisplayStruct)
foreign import ccall safe "XCloseDisplay"
closeDisplay :: Ptr DisplayStruct -> IO CInt
data DisplayStruct
main :: IO ()
main = do
withCString "localhost:0.0" $ \cstr -> do
print "before"
p <- openDisplay cstr
print "after"
closeDisplay p
print "done"
</pre><hr />
<p>
Another example, but instead partially using C code.
Works fine on linux, but not on windows.
</p>
<p>
If writing the program entirely in C, it works. But if replacing main in the C
program with a call from haskell code through ffi, then it does not work
anymore.
</p>
<p>
c-file:
</p>
<pre class="wiki">
#include <X11/Xlib.h>
#include <stdio.h>
void ProgFunc(){
printf("ProgFunc starting\n");
Display *dpy = XOpenDisplay(":0.0");
printf("dpy: 0x%x\n", (unsigned int)dpy);
}
/* it works if using this main. (thus only C code compiled with GCC)
main()
{
ProgFunc();
return 0;
}
*/
</pre><p>
haskell-file:
</p>
<pre class="wiki">
import System.IO
foreign import ccall unsafe "ProgFunc" progFunc :: IO ()
main :: IO ()
main = do
print "before c"
progFunc
print "after c"
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1078#changelog
http://ghc.haskell.org/trac/ghc/ticket/1079
http://ghc.haskell.org/trac/ghc/ticket/1079#1079: refinement for GHC's support of UTF-8 encodingTue, 02 Jan 2007 15:05:09 GMTmukai@…<p>
From 6.6, GHC supports UTF-8 encoding in the source programs. GHC can read UTF-8 files and convert them into Unicode characters. However, there are no support to read/print them.
</p>
<p>
For example, we can compile the following program,
</p>
<pre class="wiki">main = putStrLn "あ"
</pre><p>
but we only get <tt>B</tt>, the least 8bit of the character <tt>あ</tt> (U+3042). Because of this incompleteness, we cannot print any non-ascii characters without converting for the case of writing Haskell codes with UTF-8. Although it is easy to write converting functions for this purpose, such converting should be supported by the compiler.
</p>
<p>
IMHO, desired approach is similar to Hugs. In Hugs, when printing non-ascii characters, it first converts the characters to UTF-8 octets and then prints them. However, with binary-mode Handle, it just print characters without convert. This behavior will be acceptable for many haskell programmers.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1079#changelog
http://ghc.haskell.org/trac/ghc/ticket/1082
http://ghc.haskell.org/trac/ghc/ticket/1082#1082: Documentation missing from MacOS PPC binaryThu, 04 Jan 2007 05:28:23 GMTguest<p>
The installation from the MacOS PPC binary distribution works fine but ends with
</p>
<pre class="wiki">=======================================================================
Installation of ghc-6.6 was successful.
To use, add /usr/local/bin to your PATH.
For documentation, see /usr/local/share/ghc-6.6/html/index.html
=======================================================================
</pre><p>
However, there is no documentation there, nor does <tt>make html</tt> work. And unfortunately for us who often work offline, there doesn't seem to be a separate download for the documentation.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1082#changelog
http://ghc.haskell.org/trac/ghc/ticket/1083
http://ghc.haskell.org/trac/ghc/ticket/1083#1083: ghci says a module wasn't loaded under debugging mode when in fact it wasThu, 04 Jan 2007 09:44:19 GMTmnislaih<p>
When loading an empty module like the following:
</p>
<pre class="wiki">main = putStr "hola"
</pre><p>
ghci will refuse to set a breakpoint saying that the module is not loaded under debugging mode
</p>
<pre class="wiki">pepe:~/code/snippets$ ghci -fdebugging main
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.7, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( main.hs, interpreted )
Ok, modules loaded: Main.
*Main> :break add Main 1
*** Exception: Module main:Main was not loaded under debugging mode. Enable debugging mode and reload it
*Main>
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1083#changelog
http://ghc.haskell.org/trac/ghc/ticket/1084
http://ghc.haskell.org/trac/ghc/ticket/1084#1084: Improve coalescing of dynamic breakpoints in the ghci debuggerThu, 04 Jan 2007 09:51:07 GMTmnislaih<p>
(or disable it altogether)
</p>
<p>
Right now coalescing of breakpoints works at instrumentation time by:
</p>
<ol><li>Not inserting a breakpoint if there are no local bindings in the site
</li><li>Removing adjacent breakpoints, i.e. removing one of them (not implemented yet)
</li><li>adhoc case: if we are about to insert a breakpoint but the subexpresion is a HsLet, then don't.
</li></ol><p>
Proposal is to disable cases 1 and 3 and implement case 2 using rewriting rules.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1084#changelog
http://ghc.haskell.org/trac/ghc/ticket/1089
http://ghc.haskell.org/trac/ghc/ticket/1089#1089: Somewhat bad type error messageMon, 08 Jan 2007 02:51:02 GMTkirsten<pre class="wiki">module Small where
import Data.Maybe
filterNothings :: [[Maybe a]] -> [[a]]
filterNothings xs = {- (map catMaybes) -} (filter someFun xs)
someFun = all isJust
-- Compiling the above code gives the following rather bad error message (in ghci 6.6):
{-
Small.hs:5:63:
Couldn't match expected type `a' (a rigid variable)
against inferred type `Maybe a'
`a' is bound by the type signature for `filterNothings'
at Small.hs:4:26
Expected type: [[a]]
Inferred type: [[Maybe a]]
In the second argument of `filter', namely `xs'
In the expression: (filter (const True) xs)
-}
-- My error was leaving out the "(map catMaybes)" part, in the comment.
-- I think that the error message shouldn't say anything about rigid variables,
-- or at least, I find that confusing, as well as the fact that the error message
-- mentions [a] -> Bool. The problem is the return type of the application
-- of filter is [[Maybe a]], and the type signature I gave for filterNothings has the
-- return type [[a]]. In an ideal world, the error message would point out that the type
-- [[a]] doesn't match [[Maybe a]], without the additional noise. Indeed, if I change
-- someFun to (const True), I do get the error message I'd like, although it still
-- uses the word "rigid", which I find suboptimal.
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1089#changelog
http://ghc.haskell.org/trac/ghc/ticket/1090
http://ghc.haskell.org/trac/ghc/ticket/1090#1090: Bad monomorphism-restriction-related type error messageMon, 08 Jan 2007 04:04:50 GMTkirsten<p>
Consider the following program:
</p>
<pre class="wiki">module Small2 where
printFormatted :: IO ()
printFormatted =
let myPrint :: (a -> String) -> a -> IO ()
myPrint f s = putStr (f s)
-- myShow :: Show a => a -> IO ()
myShow = myPrint show in
myShow 1 >> myShow "foo"
</pre><p>
If I compile this I get:
</p>
<pre class="wiki">> ghc --make -no-recomp -c small2.hs
[1 of 1] Compiling Small2 ( small2.hs, small2.o )
small2.hs:9:19:
No instance for (Num [Char])
arising from the literal `1' at small2.hs:9:19
Possible fix: add an instance declaration for (Num [Char])
In the first argument of `myShow', namely `1'
In the first argument of `(>>)', namely `myShow 1'
In the expression:
let
myPrint :: (a -> String) -> a -> IO ()
myPrint f s = putStr (f s)
myShow = myPrint show
in (myShow 1) >> (myShow "foo")
</pre><p>
The fix, of course, is to either add -fno-monomorphism-restriction or to uncomment the type signature for <tt>myShow</tt>, but it took me a while to figure that out. It would be much better if the error message would suggest adding a type signature for <tt>myShow</tt>. As it is, the suggestion to add an instance for <tt>Num [Char]</tt> is none too helpful.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1090#changelog
http://ghc.haskell.org/trac/ghc/ticket/1099
http://ghc.haskell.org/trac/ghc/ticket/1099#1099: Visual Haskell crashes when ".." is used in hs-source-dirsMon, 15 Jan 2007 10:54:43 GMTganesh.sittampalam@…<p>
Create a new Visual Haskell project, manually edit the .cabal file to include ".." in "hs-source-dirs", then create a .hs file in it and try to edit that file.
</p>
<p>
I'm using the updated vs_haskell.dll from <a class="ext-link" href="http://www.haskell.org/visualhaskell/release-0.2/vs_haskell.zip"><span class="icon"></span>http://www.haskell.org/visualhaskell/release-0.2/vs_haskell.zip</a>
</p>
<p>
This is the error signature Visual Studio lists:
</p>
<pre class="wiki">AppName: devenv.exe AppVer: 8.0.50727.42 AppStamp:4333e699
ModName: vs_haskell.dll ModVer: 0.0.0.0 ModStamp:45804f05
fDebug: 0 Offset: 00a97f4b
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1099#changelog
http://ghc.haskell.org/trac/ghc/ticket/1100
http://ghc.haskell.org/trac/ghc/ticket/1100#1100: Parse error on (#) in .lhs filesMon, 15 Jan 2007 19:18:55 GMTj.russell@…<p>
The lexeme sequence <tt>(#)</tt> gives a parse error in .lhs files.
This makes it impossible to, among other things,
give a type signature to the operator <tt>#</tt>
</p>
<p>
I believe that this should be legal.
</p>
<p>
For instance, the line
</p>
<pre class="wiki">(#) :: Foo -> Bar -> Quux
</pre><p>
gives a parse error in a .lhs file.
The same line in a .hs file compiles normally.
</p>
<p>
This may be related to bug <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/733" title="bug: Problem compiling .lhs files with lines that begin with # (closed: duplicate)">#733</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1100#changelog
http://ghc.haskell.org/trac/ghc/ticket/1102
http://ghc.haskell.org/trac/ghc/ticket/1102#1102: Lambda unicode character lexMon, 15 Jan 2007 20:54:47 GMThumasect<p>
abd ∷ Num a ⇒ a → a
abd a = a
</p>
<p>
(⋴) a b = a ++ b
test2 x = map (λx → x ⋴ "abc") -- line 17
</p>
<p>
Test.hs:17:18: parse error on input `?'
</p>
<hr />
<p>
All of these special characters are unicode, and work great, except the lambda. Any unicode character put here gives this error. <a class="ext-link" href="http://hackage.haskell.org/trac/haskell-prime/wiki/UnicodeInHaskellSource"><span class="icon"></span>http://hackage.haskell.org/trac/haskell-prime/wiki/UnicodeInHaskellSource</a> -- claims otherwise.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1102#changelog
http://ghc.haskell.org/trac/ghc/ticket/1105
http://ghc.haskell.org/trac/ghc/ticket/1105#1105: Custom RuntimesTue, 16 Jan 2007 06:35:21 GMThumasect<p>
The ability to build custom runtimes would be useful in many development situations. Like Objective Caml's -custom, one would be able to create a interactive-invokable (GHCi) with a custom main () initialization and finalizer. For things such as SDL applications, Cocoa applications, there is a need for custom run loops as well. This would be an immensely great integration feature for GHC. In these situations it is not possible to work in GHCi on most/all platforms without much work done in a specialized hs-plugins REPL environment.
</p>
<p>
Ideas of Requirements:
</p>
<ul><li>specifiable initializer (from main)
</li><li>specifiable finalizer
</li><li>specifiable run loop / event handler (light thread) as such:
<ul><li>REPL
</li><li>thread 0 - read, eval (send to thread 1), print, loop
</li><li>thread 1 - processing events run loop, check for eval + send result to print stage
</li></ul></li></ul><p>
[the author is developing a Cocoa+GL native application in 100% Haskell sans HOC sans HOpenGL]
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1105#changelog
http://ghc.haskell.org/trac/ghc/ticket/1107
http://ghc.haskell.org/trac/ghc/ticket/1107#1107: Incorrect error message when there is a dot in the package name.Wed, 17 Jan 2007 13:46:19 GMTkr.angelov<p>
Bruno Martínez reported:
</p>
<p>
I wanted to name a project of mine, xyz.hs, because xyz is the
c++ verison. I get
</p>
<p>
<stderr>: hPutChar: invalid argument (Bad file descriptor)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1107#changelog
http://ghc.haskell.org/trac/ghc/ticket/1112
http://ghc.haskell.org/trac/ghc/ticket/1112#1112: The testsuite setup is brokenSun, 21 Jan 2007 04:58:15 GMTguest<p>
I just ran the ghc regression test on my MacBook. It says:
</p>
<p>
OVERALL SUMMARY for test run started at Sat Jan 20 18:26:17 EST 2007
...
</p>
<blockquote>
<p>
266 unexpected failures
</p>
</blockquote>
<p>
So either my setup is totally wrong (I have the latest sources), or the testsuite is
not set up right. The point of a test suite is that you should be able to run it
before and after a change and see if something bad has happened. If the norm
is to get unexpected failures, then they are not unexpected, are they?
</p>
<p>
So which is it? Did I miss something setting up ghc, or does is the test suite giving
unexpected failures normally? If it's the latter I strongly recommend changing how
the suite is set up. There might be failures that should be fixed, but that are still
expected at the moment. Well, then say so.
</p>
<p>
Lennart
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1112#changelog
http://ghc.haskell.org/trac/ghc/ticket/1120
http://ghc.haskell.org/trac/ghc/ticket/1120#1120: randomR is non-uniform for most rangesFri, 26 Jan 2007 14:29:37 GMTastrolabe<p>
If m < n, you can't convert a uniform random sample from [0,n-1]
to one from [0,m-1] using mod unless m|n. For example, if
m = n-1 then the getting 0 is twice as likely as getting anything
else. However, this scheme is what seems to be used in this function from
<a class="ext-link" href="http://darcs.haskell.org/ghc-6.6/packages/base/System/Random.hs"><span class="icon"></span>http://darcs.haskell.org/ghc-6.6/packages/base/System/Random.hs</a>
</p>
<pre class="wiki">randomIvalInteger :: (RandomGen g, Num a) => (Integer, Integer) -> g -> (a, g)
randomIvalInteger (l,h) rng
| l > h = randomIvalInteger (h,l) rng
| otherwise = case (f n 1 rng) of (v, rng') -> (fromInteger (l + v `mod` k), rng')
where
k = h - l + 1
b = 2147483561
n = iLogBase b k
f 0 acc g = (acc, g)
f n acc g =
let
(x,g') = next g
in
f (n-1) (fromIntegral x + acc * b) g'
</pre><p>
One possible fix is to repeatedly sample from [0,n-1] until you get
a value that is in [0,floor(n/m)*m-1]. This would work practically, but
is not gauranteed to terminate. You should, in my opinion, at least try
a few samples before accepting one that isn't in this range.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1120#changelog
http://ghc.haskell.org/trac/ghc/ticket/1121
http://ghc.haskell.org/trac/ghc/ticket/1121#1121: Error message "Expecting a function type, but found `w_a1Kh'"Fri, 26 Jan 2007 22:41:30 GMThuschi@…<p>
When compiling with GHC or loading into GHCi the following module I get a strange error:
</p>
<pre class="wiki">module Bla where
bla :: String -> String
bla x = unwords $ [ ('#':) ]
</pre><p>
The error is:
</p>
<pre class="wiki">Bug.hs:4:20:
Expecting a function type, but found `w_a1bp'
Expected type: String
Inferred type: [Char] -> [Char]
In the expression: ('#' :)
In the list element: ('#' :)
</pre><p>
Writing the function as:
</p>
<pre class="wiki">bla = words [ ('#':) ]
</pre><p>
produces the correct error message with [Char] instead of `w_a1bp'.
</p>
<p>
I was doing this with GHC-6.4.2 on Ubuntu with a 2.6.17 kernel.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1121#changelog
http://ghc.haskell.org/trac/ghc/ticket/1144
http://ghc.haskell.org/trac/ghc/ticket/1144#1144: reduction count for ghciMon, 12 Feb 2007 21:02:13 GMTguest<p>
It would be nice to extend ghci's statistics capabilities to include the number of reductions, similar to the feature already present in hugs
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1144#changelog
http://ghc.haskell.org/trac/ghc/ticket/1167
http://ghc.haskell.org/trac/ghc/ticket/1167#1167: mangler makes global symbol disappear on linux-ppcThu, 22 Feb 2007 20:11:42 GMTarekm@…<p>
Enviroment: linux-ppc, very fresh software, upcoming gcc 4.2, ghc 6.6. I was trying to build alex software which ended with:
</p>
<pre class="wiki">GNU ld version 2.17.50.0.12 20070128
Supported emulations:
elf32ppclinux
elf32ppc
elf32ppcsim
ghc3729_0.hc:(.text+0x104a): undefined reference to `ParseMonad_alexStartPos_closure'
ghc3729_0.hc:(.text+0x104e): undefined reference to `ParseMonad_alexStartPos_closure'
dist/build/alex/alex-tmp/Info.o: In function `shII_info':
ghc3729_0.hc:(.text+0x106e): undefined reference to `Util_lvl1_closure'
ghc3729_0.hc:(.text+0x1072): undefined reference to `Util_lvl1_closure'
ghc3729_0.hc:(.text+0x107a): undefined reference to `Util_lvl1_closure'
dist/build/alex/alex-tmp/Info.o:(.rodata+0x40): undefined reference to `Util_lvl1_closure'
</pre><p>
The problem is that these symbol disappear after going through mangler (so problem is visible only when -O2 is used)
</p>
<p>
In short the problem is that:
</p>
<pre class="wiki">.globl ParseMonad_alexStartPos_closure
</pre><p>
disappears.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1167#changelog
http://ghc.haskell.org/trac/ghc/ticket/1184
http://ghc.haskell.org/trac/ghc/ticket/1184#1184: Hasktags misses symbolThu, 01 Mar 2007 04:41:39 GMTnewsham<p>
(not sure I filed this bug appropriately. I belive hasktags came as part of the ghc-6.6 binary package. Please advise if there's a better place)
</p>
<p>
Hasktags is missing an obvious symbol.
</p>
<pre class="wiki">$ darcs get --partial http://happs.org/HAppS
$ cd HAppS/src
$ hasktags -c `find . -name '*.hs' |grep -v _darcs`
$ grep boolM # <- not found
$ grep boolM `find . -name '*.hs' |grep -v _darcs` # <- found
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1184#changelog
http://ghc.haskell.org/trac/ghc/ticket/1207
http://ghc.haskell.org/trac/ghc/ticket/1207#1207: Unnecessary prohibition of unquantified higher-order typeclass constraintsWed, 07 Mar 2007 14:51:41 GMTbr276@…<p>
In GHC 6.6, attempting to declare a function (say f) with a type of the form
</p>
<pre class="wiki">forall t. ... -> (Num t => ...) -> ...
</pre><p>
produces the error:
</p>
<pre class="wiki">All of the type variables in the constraint `Num t' are already in scope
(at least one must be universally quantified here)
</pre><p>
This used to make sense -- after all, there's no way f can deduce a Num constraint on t that wasn't provided by its caller, so a higher-order argument with this sort of type is uncallable. But with the addition of GADTs, this is no longer true, since another of f's arguments might, when deconstructed, reveal that t is in fact an Int or a Ratio u. In fact, GADT deconstructors can have types like this. E.g.
</p>
<pre class="wiki">data Foo a where
Bar :: forall a. Num a => a -> Foo a
</pre><p>
has a deconstructor of type
</p>
<pre class="wiki">forall a r. Foo a -> (Num a => a -> r) -> r
</pre><p>
So I think that these types should be allowed, although I haven't found a use for them yet except for writing GADT deconstructors.
</p>
<p>
On the other hand, one can't write deconstructors for most GADTs even with this change, so perhaps it's the wrong change. If explicit type equality constraints were allowed in Haskell, then I could write
</p>
<pre class="wiki">forall t. ... -> (forall t'. (t ~ t', Num t') => ...) -> ...
</pre><p>
instead.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1207#changelog
http://ghc.haskell.org/trac/ghc/ticket/1218
http://ghc.haskell.org/trac/ghc/ticket/1218#1218: Add sortNub and sortNubBy to Data.ListTue, 13 Mar 2007 03:08:32 GMTneil<p>
I propose the addition of sortNub and sortNubBy to Data.List
</p>
<p>
sortNub = sort . nub, but can run in O(n log n) instead of O(n<sup>2) with the implementation:
</sup></p>
<p>
sortNub = map head . group . sort
</p>
<p>
I personally have defined this function over 25 times. Debate on the libraries list.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1218#changelog
http://ghc.haskell.org/trac/ghc/ticket/1221
http://ghc.haskell.org/trac/ghc/ticket/1221#1221: Types don't match expressions in type errorTue, 13 Mar 2007 20:14:38 GMTigloo<p>
Frederik Eaton points out in the thread starting <a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008748.html"><span class="icon"></span>http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008748.html</a>
that with this program:
</p>
<pre class="wiki">a x = x True ++ [1]
-- ok
b = a (const [2])
-- uninformative error message
c = a y
-- more informative
d = a ()
y = const ()
</pre><p>
in the type error, for b the type doesn't match the expression: y has type
<tt>a -> ()</tt> but it claims to have infered () for it:
</p>
<pre class="wiki">v.hs:8:6:
Couldn't match expected type `[a]' against inferred type `()'
In the first argument of `a', namely `y'
In the expression: a y
In the definition of `c': c = a y
</pre><p>
(this example should be made into a testcase once we know what the error will look like).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1221#changelog
http://ghc.haskell.org/trac/ghc/ticket/1230
http://ghc.haskell.org/trac/ghc/ticket/1230#1230: write a safety wrapper around readlineThu, 15 Mar 2007 20:15:40 GMTigloo<p>
It would be nice to have a wrapper around the low-level readline functions, providing
the same functions but with types in <tt>MonadIO m => MonadReadline m</tt>. The <tt>IO</tt> monad wouldn't be in this class, but <tt>ReadlineT</tt> would be, and a <tt>withReadline</tt> function would handle calling <tt>initialize</tt> etc for you as appropriate.
</p>
<p>
Inspired by:
<a class="ext-link" href="http://www.haskell.org/pipermail/haskell-cafe/2006-October/019046.html"><span class="icon"></span>http://www.haskell.org/pipermail/haskell-cafe/2006-October/019046.html</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1230#changelog
http://ghc.haskell.org/trac/ghc/ticket/1238
http://ghc.haskell.org/trac/ghc/ticket/1238#1238: ByteString based datagram communicationTue, 20 Mar 2007 15:06:58 GMTrobreim<p>
This patch adds ByteString datagram communication.
</p>
<p>
In the process it replaces the TCP based sendTo and recvFrom functions from the Network module with ByteString / datagram equivalents. Since sendTo and recvFrom seemed to be deprecated for anything more than superficial testing, the new versions would seem more useful.
</p>
<p>
It includes a fix to ensure Network.Socket.recvBufFrom and friends handle unix file sockets.
</p>
<p>
net003 has been included for testing the new features. I have only been able to test on GHC 6.6 on linux. Attempts to test with windows and hugs caused me issues I don't currently have time to deal with. If someone with these platforms can apply the patch and run the test case, I'd be very appreciative. I'll get onto any bugs discovered when I return.
</p>
<p>
I won't be available to guide this bug through for the next 9 days but wanted to get the proposal out there ready for when I get back.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1238#changelog
http://ghc.haskell.org/trac/ghc/ticket/1239
http://ghc.haskell.org/trac/ghc/ticket/1239#1239: compare on exceptional Doubles and Floats should raise an errorTue, 20 Mar 2007 15:20:31 GMTigloo<p>
Consider:
</p>
<pre class="wiki">let n = 0/0 :: Double in (n `compare` n, n < n, n == n, n > n)
</pre><p>
In GHC and YHC this gives
</p>
<pre class="wiki">(GT,False,False,False)
</pre><p>
while in hugs it gives
</p>
<pre class="wiki">(EQ,False,False,False)
</pre><p>
Neither of these is very satisfactory, as I would expect
</p>
<pre class="wiki">x `compare` y === EQ => (x == y) === True
x `compare` y === GT => (x > y) === True
</pre><p>
and it's even less pleasant that the implementations differ for no good
reason.
</p>
<p>
The Haskell report isn't very helpful on how comparing exceptional
Doubles should behave, as it doesn't even say you need to have NaN etc:
</p>
<pre class="wiki">http://haskell.org/onlinereport/basic.html#sect6.4
The results of exceptional conditions (such as overflow or
underflow) on the fixed-precision numeric types are undefined; an
implementation may choose error (_|_, semantically), a truncated
value, or a special value such as infinity, indefinite, etc.
</pre><p>
I think that the right answer is that
</p>
<pre class="wiki">n `compare` n
</pre><p>
above
(and more generally such a comparison for any incomparable Doubles or Flaots)
should raise an error (i.e. be _|_).
</p>
<p>
The changes needed are simple, e.g. for GHC
</p>
<pre class="wiki">(D# x) `compare` (D# y) | x <## y = LT
| x ==## y = EQ
| otherwise = GT
</pre><p>
becomes
</p>
<pre class="wiki">(D# x) `compare` (D# y) | x <## y = LT
| x ==## y = EQ
| x >## y = GT
| otherwise = error "Incomparable values"
</pre><p>
Deadline: 1 week after discussion ends.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1239#changelog
http://ghc.haskell.org/trac/ghc/ticket/1245
http://ghc.haskell.org/trac/ghc/ticket/1245#1245: Turn tuples into syntactic sugar for heterogeneous listsMon, 26 Mar 2007 13:06:24 GMTbenja.fallenstein@…<p>
It would be nice if (x,y,z) were syntactic sugar for a <a class="ext-link" href="http://homepages.cwi.nl/~ralf/HList/"><span class="icon"></span>heterogeneous list</a>, i.e. (x :*: y :*: z :*: HNil) where
</p>
<pre class="wiki">data a :*: b = a :*: b
data HNil = HNil
</pre><p>
(:*: associating to the right). Using functional dependencies and the techniques from the HList paper, we could then process tuples of arbitrary length in a uniform matter: for example, the Data.Monoid.Monoid instances for tuples. At the same time, this would create a slightly more light-weight syntax for heterogeneous lists, making them more acceptable for use cases like functions with optional or keyword arguments.
</p>
<p>
I'm not sure how much existing code would this would break. Showing and reading heterogeneous lists as tuples doesn't seem hard to implement. I don't know about Typeable and friends.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1245#changelog
http://ghc.haskell.org/trac/ghc/ticket/1249
http://ghc.haskell.org/trac/ghc/ticket/1249#1249: Data.Map.map should be deprecated/removedWed, 28 Mar 2007 02:34:25 GMTajb@…<p>
(Note: Every claim here referring to Data.Map.map applies equally well to Data.IntMap.map.)
</p>
<p>
I believe that Data.Map.map is a misfeature and should be deprecated or removed.
</p>
<ol><li>Its name clashes with an extremely commonly-used Prelude function. This makes the first import of Data.Map into an existing module very expensive. Either all existing instances of "map" need to be qualified, or the import of Data.Map needs to be qualified (which works, but makes (!) and (<br />) unnecessarily inelegant), or the import must hide map.
</li></ol><ol start="2"><li>There is an easy way to get at the functionality which is already implemented: use fmap.
</li></ol><p>
Data.Set.map and Data.IntSet.map have similar problems, however you can't just "use fmap" in that case. I don't have a good solution except to rename these.
</p>
<p>
Data.Map.null also clashes with the Prelude, and should be reconsidered. However, again, there isn't a simple workaround, and there are many more overloadings of null (e.g. Data.ByteString). It's also likely that null is used far less than map, so the cost of a clash is much lower.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1249#changelog
http://ghc.haskell.org/trac/ghc/ticket/1257
http://ghc.haskell.org/trac/ghc/ticket/1257#1257: Bytecode generator can't handle unboxed tuplesSat, 31 Mar 2007 19:30:32 GMTigloo<p>
We need to implement unboxed tuple support in ghci.
</p>
<p>
For example, with:
</p>
<pre class="wiki">f :: a -> b -> (# a, b #)
f x y = (# x, y #)
</pre><p>
we get:
</p>
<pre class="wiki">$ ghci -v0 -fglasgow-exts w.hs
ghc-6.6: panic! (the 'impossible' happened)
(GHC version 6.6 for x86_64-unknown-linux):
Bytecode generator can't handle unboxed tuples. Possibly due
to foreign import/export decls in source. Workaround:
compile this module to a .o file, then restart session.
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1257#changelog
http://ghc.haskell.org/trac/ghc/ticket/1266
http://ghc.haskell.org/trac/ghc/ticket/1266#1266: Make Data.Graph.Inductive.NodeMap handle slightly messy input without crashingWed, 04 Apr 2007 06:29:40 GMTjyasskin@…<p>
Using the current version of Data.Graph.Inductive casually is unnecessarily difficult because if you insert a node that's already present in the graph, or try to insert an edge with an endpoint that's not already in the graph, the library crashes. For the raw graph operations that's somewhat reasonable since it wouldn't know what labels to use. NodeMap, on the other hand, has plenty of information, so this patch makes it safer in these cases.
</p>
<p>
I've also added the beginning of a test suite runnable with <tt>runhaskell Setup.hs test</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1266#changelog
http://ghc.haskell.org/trac/ghc/ticket/1274
http://ghc.haskell.org/trac/ghc/ticket/1274#1274: Add a MonadState instance for the Parsec monadFri, 13 Apr 2007 18:26:35 GMTmux<p>
This patch adds a MonadState instance for the GenParser monad of Parsec, allowing the use of the usual state handling primitives instead of the custom ones provided by Parsec.
</p>
<p>
The drawback of this is that it adds a dependency on mtl; I don't think that's much of a problem though, and we'll need it for ParsecT anyways.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1274#changelog
http://ghc.haskell.org/trac/ghc/ticket/1293
http://ghc.haskell.org/trac/ghc/ticket/1293#1293: building via gcc 4.2.x on SPARC/Solaris is very slowThu, 26 Apr 2007 13:25:13 GMTmm<pre class="wiki">../../compiler/ghc-inplace -H16m -O -package-name haskell-src-1.0.1 -O -Rghc-timing -fgenerics
-package base -fgenerics -split-objs -hisuf p_hi -hcsuf p_hc -osuf p_o -prof -c Language/Haskell/Syntax.hs -o Language/Haskell/Syntax.p_o -ohi Language/Haskell/Syntax.p_hi
^C
<<ghc: 1692957264 bytes, 2394 GCs, 12868709/19559532 avg/max bytes residency (12 samples), 50M in use, 0.00 INIT (0.00 elapsed), 9.28 MUT (9.52 elapsed), 3.22 GC (3.50 elapsed) :ghc>>
make[3]: *** [Language/Haskell/Syntax.p_o] Fehler 1
make[2]: *** [all] Unterbrechung
make[1]: *** [all] Unterbrechung
make: *** [stage1] Unterbrechung
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1293#changelog
http://ghc.haskell.org/trac/ghc/ticket/1299
http://ghc.haskell.org/trac/ghc/ticket/1299#1299: "sh boot" should give a better error message if automake isn't installedThu, 26 Apr 2007 18:10:11 GMTchevalier@…<p>
I was building GHC from scratch on a new machine that didn't have automake installed, and sh boot gave the following error message:
Can't exec "aclocal": No such file or directory at /usr/bin/autoreconf line 182.
Use of uninitialized value in pattern match (m<em>) at /usr/bin/autoreconf line 18 2.
Can't exec "automake": No such file or directory at /usr/bin/autoreconf line 183 .
Use of uninitialized value in pattern match (m</em>) at /usr/bin/autoreconf line 18 3.
(repeated five times)
</p>
<p>
It would be nice if the script checked whether automake was installed. Or, at least, maybe if the first attempt to use automake failed, there might be a way to avoid printing out the same error message five times; it's a little forbidding. (I'm sure the documentation says you need automake, but it might be nice to have a better error message even so.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1299#changelog
http://ghc.haskell.org/trac/ghc/ticket/1323
http://ghc.haskell.org/trac/ghc/ticket/1323#1323: crash when zipping two lists of the same length...Thu, 03 May 2007 14:36:28 GMTmatthew@…<p>
I've personally not checked this against 6.6.1, but "mauke" on #haskell says the same crash and same line number appears in the crash report.
</p>
<pre class="wiki">$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.6
$ ghc -v --make Session.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
hiding package hinstaller-2007.4.21 to avoid conflict with later version hinstaller-2007.4.24
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: Session.hs
Stable obj: []
Stable BCO: []
compile: input file Session.hs
Created temporary directory: /tmp/ghc4588_0
*** Checking old interface for main:Main:
[1 of 1] Compiling Main ( Session.hs, Session.o )
*** Parser:
*** Renamer/typechecker:
*** Desugar:
Result size = 379
*** Simplify:
*** Deleting temp files:
Deleting: /tmp/ghc4588_0/ghc4588_0.s
Warning: deleting non-existent /tmp/ghc4588_0/ghc4588_0.s
*** Deleting temp dirs:
Deleting: /tmp/ghc4588_0
ghc-6.6: panic! (the 'impossible' happened)
(GHC version 6.6 for x86_64-unknown-linux):
Pattern match failure in do expression at simplCore/Simplify.lhs:1540:8-21
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
</pre><p>
Now as the comments in the source say, it works fine if you replace newtype with data, and I am aware that there are differences in what they do, though I can never quite remember the fine details. So it's quite possibly my fault, but an error message other than a GHC crash would be nicer!
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1323#changelog
http://ghc.haskell.org/trac/ghc/ticket/1324
http://ghc.haskell.org/trac/ghc/ticket/1324#1324: threadDelay can't handle long timesThu, 03 May 2007 17:12:56 GMTguest<p>
With (Control.Concurrent.threadDelay :: Int -> IO ()) and the parameter interpreted as microseconds, the longest delay time is some 35 minutes, which I find somewhat short. Of course it's possible to call threadDelay several times to implement longer delays, but I ask whether this is the interface we want to have.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1324#changelog
http://ghc.haskell.org/trac/ghc/ticket/1334
http://ghc.haskell.org/trac/ghc/ticket/1334#1334: apparent memory leak in --make mode (compiling base library during building ghc)Sat, 05 May 2007 20:34:21 GMTIsaac Dupree<p>
I've noticed that my memory usage slowly goes up and up, and not down until the <tt>ghc-inplace ... --make ... -O ...</tt> of all base at once finishes. There is not such a memory reduction between the individual file compilations within the --make. By the end it's using around 200-400 MB of memory. Compiling files individually doesn't seem to have such a large memory occupancy. I could probably gather more details/sureness if it would be useful... for now I am just noting this effect. (I think when I built jhc, which is built using ghc --make, it also ended up using large amounts of memory.) Is the high memory usage just a symptom of importing lots of modules even with separate invocations of ghc, or is ghc remembering more than it needs to in --make mode, or does remembering all the .hi contents at once, of all modules that have been compiled and will be needed sometime in future compilation, take that much memory?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1334#changelog
http://ghc.haskell.org/trac/ghc/ticket/1336
http://ghc.haskell.org/trac/ghc/ticket/1336#1336: +RTS options should warn on the compilerSun, 06 May 2007 16:32:15 GMTsorear<pre class="wiki"><tcr> ghc --make Main.hs +RTS -xc
<tcr> doesn't work, I must be misunderstanding something
</pre><p>
is one of the most common misunderstandings on #haskell. Would it be feasable to have GHC generate a warning if passed a +RTS option?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1336#changelog
http://ghc.haskell.org/trac/ghc/ticket/1350
http://ghc.haskell.org/trac/ghc/ticket/1350#1350: Win 9x supportSat, 12 May 2007 00:23:33 GMTigloo<p>
Sigbjorn wrote the below re his GHC 6.6.1 installer. It sounds like there still is some demand for GHC on Win 9x, so we should have make a non-threaded ghc be built in the nightly builds and handled correctly in the installer creator.
</p>
<pre class="wiki">Someone sent an e-mail querying about Win9x compatibility, which
is something I forgot to take into account when building the 6.6.1
installer. To remedy, I've refreshed the installer to include a new
version that ought to work across a wider spectrum of MS OS
versions & releases --
http://galois.com/~sof/msi/ghc-6-6-1.msi
Notice that since the GHC binary is now being linked with
a 'threaded' RTS, some non-Win9x compatible portions of the
Win32 API is being used & depended upon, causing DLL resolution
at startup to miserably fail.
To counter and workaround this, I've included bin/ghc-u.exe with
the refreshed installer, which is an unthreaded (and faster..) version
of the compiler (=> GHCi.) So, to get a working system under
Win9x, you'll need to either use "ghc-u" directly, or rename it
as ghc.exe (and, as a result, enable 'ghci.exe' usage.)
Also, as with ghc-6.6, if you intend to distribute your 6.6.1-compiled
code that uses the Win32 package, and have it work on Win9x
platforms, you'll need to include the Unicode API layer DLL, which
you'll find in bin/ as unicows.dll
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1350#changelog
http://ghc.haskell.org/trac/ghc/ticket/1361
http://ghc.haskell.org/trac/ghc/ticket/1361#1361: When trying to run yi, it fails to compile main, and exits with an errorFri, 18 May 2007 14:09:51 GMTguest<p>
I am using ghc-6.6.1 installed in a non-standard location, and I just built yi-0.2 also for a non-standard location, and the first time I run it I get:
</p>
<pre class="wiki"><interactive>:1:33:
Failed to load interface for `Yi':
Use -v to see a list of the files searched for.
yi: panic! (the 'impossible' happened)
(GHC version 6.6.1 for i386-unknown-linux):
Could not compile Yi.main!
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
</pre><p>
The output from the configuration and build is:
</p>
<pre class="wiki">$ runhaskell Setup.hs configure --prefix=/design/local/yi
Configuring yi-0.2...
configure: Dependency ghc>=6.6: using ghc-6.6.1
configure: Dependency base-any: using base-2.1.1
configure: Dependency mtl-any: using mtl-1.0.1
configure: Dependency regex-posix-any: using regex-posix-0.71
configure: Using install prefix: /design/local/yi
configure: Binaries installed in: /design/local/yi/bin
configure: Libraries installed in: /design/local/yi/lib/yi-0.2/ghc-6.6.1
configure: Private binaries installed in: /design/local/yi/libexec
configure: Data files installed in: /design/local/yi/share/yi-0.2
configure: Using compiler: /design/local/ghc-6.6.1/bin/ghc
configure: Compiler flavor: GHC
configure: Compiler version: 6.6.1
configure: Using package tool: /design/local/ghc-6.6.1/bin/ghc-pkg
configure: Using ar found on system at: /usr/bin/ar
configure: No haddock found
configure: No pfesetup found
configure: Using ranlib found on system at: /usr/bin/ranlib
configure: Using runghc found on system at: /design/local/ghc-6.6.1/bin/runghc
configure: No runhugs found
configure: No happy found
configure: No alex found
configure: Using hsc2hs: /design/local/ghc-6.6.1/bin/hsc2hs
configure: No c2hs found
configure: No cpphs found
configure: No greencard found
$ runhaskell Setup.hs build
Preprocessing executables for yi-0.2...
Building yi-0.2...
[1 of 4] Compiling Yi.Kernel ( Yi/Kernel.hs, dist/build/yi/yi-tmp/Yi/Kernel.o
)
[2 of 4] Compiling Yi.Debug ( Yi/Debug.hs, dist/build/yi/yi-tmp/Yi/Debug.o )
[3 of 4] Compiling Yi.Boot ( Yi/Boot.hs, dist/build/yi/yi-tmp/Yi/Boot.o )
[4 of 4] Compiling Main ( Main.hs, dist/build/yi/yi-tmp/Main.o )
Linking dist/build/yi/yi ...
$ runhaskell Setup.hs install
Installing: /design/local/yi/lib/yi-0.2/ghc-6.6.1 & /design/local/yi/bin yi-0.2...
</pre><p>
My machine is:
</p>
<pre class="wiki">$ cat /etc/redhat-release
Red Hat Enterprise Linux WS release 3 (Taroon Update 7)
$ uname -a
Linux carl 2.4.21-40.ELhugemem #1 SMP Thu Feb 2 22:14:10 EST 2006 i686 i686 i386 GNU/Linux
</pre><p>
Let me know if there is any more info I can provide.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1361#changelog
http://ghc.haskell.org/trac/ghc/ticket/1369
http://ghc.haskell.org/trac/ghc/ticket/1369#1369: Type error when compiling ST-monad-like codeMon, 21 May 2007 14:13:35 GMTkoen@…<p>
Compiling the module below works fine in GHC 6.4.2. In GHC 6.6 and 6.6.1, it gives a type error.
</p>
<p>
/Koen
</p>
<pre class="wiki">{-# OPTIONS -fglasgow-exts #-}
module Bug where
import Control.Monad.ST
import Data.STRef
newtype M s a =
MkM (STRef s Int -> ST s a)
runM :: (forall s . M s a) -> a
runM mm =
runST (
do ref <- newSTRef 0
m ref
)
where
MkM m = mm
-- the instance declaration and function definition
-- of "inc" are just here for giving context;
-- removing them still makes runM not type check in GHC 6.6
instance Monad (M s) where
return x =
MkM (\_ -> return x)
MkM m >>= k =
MkM (\ref ->
do x <- m ref
let MkM m' = k x
m' ref
)
inc :: M s Int
inc = MkM (\ref ->
do n <- readSTRef ref
writeSTRef ref (n+1)
return n
)
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1369#changelog
http://ghc.haskell.org/trac/ghc/ticket/1383
http://ghc.haskell.org/trac/ghc/ticket/1383#1383: mistaken qualified infix syntax could have a nicer error messageSun, 27 May 2007 17:52:39 GMTIsaac Dupree<p>
Consider the expression <tt> Prelude.(+) </tt>;
we get <tt>Not in scope: data constructor `Prelude'</tt>.
Unfortunately this is valid code if the module-referencing name also is the name of an in-scope data constructor. In the common case that it isn't, at least (a cursory inspection doesn't find any such exports in the libraries, e.g. Data.Map doesn't export a data-constructor Map), a message to the effect that infix operators must be qualified like (Prelude.+) instead, would be nice. (hierarchical module names probably make this a little more complicated somehow)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1383#changelog
http://ghc.haskell.org/trac/ghc/ticket/1393
http://ghc.haskell.org/trac/ghc/ticket/1393#1393: Tag source tree with successful bootstrapsWed, 30 May 2007 13:37:58 GMTguest<p>
Trying to keep up with ghc HEAD can be very frustrating. If you grab the source tree at any point in time there only seems to be about a 10% chance that the compiler can actually successfully bootstrap itself and all the libraries.
I suggest that the nightly build should tag the tree when it has successfully bootstrapped everything (for each platform). This way there would be recent and working fall-back points.
</p>
<p>
Alternatively, make sure that bootstrapping works before pushing the change into the main repo (but given the speed of recompilation this could be painful).
</p>
<blockquote>
<p>
-- Lennart
</p>
</blockquote>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1393#changelog
http://ghc.haskell.org/trac/ghc/ticket/1408
http://ghc.haskell.org/trac/ghc/ticket/1408#1408: groupWhen – a groupBy that compares consecutive valuesSun, 03 Jun 2007 21:49:41 GMTJoachim Breitner <mail@…><p>
<tt>groupBy</tt> has a minor problem: It always uses the first value of a group to decide whether a new value belongs to this group or the next. In several cases it would be more useful if it would take the last value of a group, thus always comparing consecutive values.
</p>
<p>
Example code:
</p>
<pre class="wiki">groupWhen :: (a -> a -> Bool) -> [a] -> [[a]]
groupWhen _ [] = []
groupWhen _ [a] = [[a]]
groupWhen f (a:l) = if f a (head c) then (a:c):r
else [a]:c:r
where (c:r) = groupWhen f l
</pre><p>
Uses:
</p>
<pre class="wiki">groupWhen (\a b -> b - a < 5) [1,2,4,10,14,16,18] -- Finding holes in a increasing series, e.g. log time stamps (my real use case)
</pre><p>
or
</p>
<pre class="wiki">groupWhen (<) [1,2,3,2,10,12,10,11] -- Group into strictly increasing sublists
</pre><p>
Note that for transitive and symetrical comparision functions <tt>f</tt> (such as <tt>(==)</tt>), <tt>groupBy f == groupWhen f</tt>.
</p>
<p>
It should probably go to Data.List
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1408#changelog
http://ghc.haskell.org/trac/ghc/ticket/1455
http://ghc.haskell.org/trac/ghc/ticket/1455#1455: Wildcard pattern _ generates defaulting warningFri, 22 Jun 2007 15:02:55 GMTguest<p>
The <em>second</em> use of properFraction generates a Defaulting warning, even though the Integral value in question is being thrown away:
</p>
<pre class="wiki">module Main where
r :: Double
r = pi
main :: IO ()
main =
let (_,x) = properFraction r :: (Integer,Double)
(_,y) = properFraction r
in putStrLn $ show (x,y)
</pre><p>
It is clearly trivial to work around this issue. However, if one takes the point of view that all of one's final code should compile using the -Wall -Werror flags, then the work around confirms dynamic typers' worst fears about Haskell. One shouldn't have to say anything about a value that's being thrown away; the compiler should make the most efficient call what to do, not e.g. some tightly wound mathematician who believes that Integer is the only valid Integral type.
</p>
<p>
Here is the compiler output:
</p>
<pre class="wiki">% ghc -v -Wall -Werror Bug.hs
Glasgow Haskell Compiler, Version 6.6, for Haskell 98, compiled by GHC version 6.6
Using package config file: /usr/local/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
Created temporary directory: /tmp/ghc12130_0
*** Checking old interface for main:Main:
*** Parser:
*** Renamer/typechecker:
Bug.hs:9:15:
Warning: Defaulting the following constraint(s) to type `Integer'
`Integral t' arising from use of `properFraction' at Bug.hs:9:15-30
In the expression: properFraction r
In a pattern binding: (_, y) = properFraction r
In the expression:
let
(_, x) = properFraction r :: (Integer, Double)
(_, y) = properFraction r
in putStrLn $ (show (x, y))
*** Deleting temp files:
Deleting: /tmp/ghc12130_0/ghc12130_0.s
Warning: deleting non-existent /tmp/ghc12130_0/ghc12130_0.s
*** Deleting temp dirs:
Deleting: /tmp/ghc12130_0
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1455#changelog
http://ghc.haskell.org/trac/ghc/ticket/1458
http://ghc.haskell.org/trac/ghc/ticket/1458#1458: FPS package dependency in GHC 6.4 and GHC 6.6Sat, 23 Jun 2007 18:58:05 GMTghc@…<p>
When switching from GHC-6.4 to GHC-6.6 I must remove all FPS dependencies in Cabal, which is not only very annoying, but seems to be unnecessary. I understand that ByteStrings are now integral part of the GHC package, but why can't there be an FPS package, maybe a dummy package, that must be imported for using ByteStrings?
Remember that this is not only about switching from 6.4 to 6.6: I have different machines with different versions of GHC, thus I have to work with both versions simultaneously.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1458#changelog
http://ghc.haskell.org/trac/ghc/ticket/1488
http://ghc.haskell.org/trac/ghc/ticket/1488#1488: Code that won't ever be executed should not give rise to constraintsTue, 03 Jul 2007 20:47:50 GMTiampure@…<p>
In the code
</p>
<pre class="wiki">a x = let b = show x in 5,
</pre><p>
ghci derives:
</p>
<pre class="wiki">a :: (Show a, Num t) => a -> t,
</pre><p>
which is correct, but I think the rules should be slightly altered, since in reality giving something to a which is not an instance of Show wouldn't be a problem, since it's not used in the first place.
</p>
<p>
One important application of this is testing a general data structure for one specific element type with assertions in the the general code and having a switch to turn generic and non-generic mode on and off. Unfortunately, this approach doesn't work today, since all kinds of constraints that are essentially part of the debugging process get added. Since deciding whether a certain variable is used is very easy in this setting(for example CPP macros that expand into "if debugging", where debugging will have a constant value. (I don't expect you to solve the Halting Problem).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1488#changelog
http://ghc.haskell.org/trac/ghc/ticket/1499
http://ghc.haskell.org/trac/ghc/ticket/1499#1499: Visual Haskell installer issue(s)Fri, 06 Jul 2007 09:17:22 GMTsimonmar<p>
There appears to be one or more installer bugs in Visual Haskell 0.2, reported on glasgow-haskell-bugs:
</p>
<ul><li><a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008721.html"><span class="icon"></span>http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008721.html</a>
</li><li><a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008797.html"><span class="icon"></span>http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008797.html</a>
</li><li><a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008888.html"><span class="icon"></span>http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008888.html</a>
</li><li><a class="ext-link" href="http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008954.html"><span class="icon"></span>http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008954.html</a>
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1499#changelog
http://ghc.haskell.org/trac/ghc/ticket/1506
http://ghc.haskell.org/trac/ghc/ticket/1506#1506: Case-insensitive char/string comparisonFri, 06 Jul 2007 16:39:55 GMTEelis<p>
Data.Char provides functions to convert case, but does not provide a function to perform case-insensitive char/string comparison. Note that such functionality cannot be obtained by simply comparing for equality after performing toUpper/toLower, because some languages have things like multiple lowercase characters corresponding to the same uppercase character.
</p>
<p>
For example, in Greek, converting either σ or ς to uppercase yields Σ, while the inverse always yields σ. Consequently, the convert-all-to-uppercase approach would produce a false positive when comparing σ to ς, and the convert-all-to-lowercase approach would produce a false negative when comparing Σ to ς.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1506#changelog
http://ghc.haskell.org/trac/ghc/ticket/1508
http://ghc.haskell.org/trac/ghc/ticket/1508#1508: hasktags program needs replacementSat, 07 Jul 2007 13:49:03 GMTiampure@…<p>
The following module yields
</p>
<p>
HaskTagsTest.hs,0
</p>
<p>
It should have included the identifier a, b, c and d in the TAGS file. My suggestion would be to remove it from the manual and stop distributing it or to replace it, since also on real code it is of no help and only wastes time.
</p>
<pre class="wiki">module Zork where
a = putStrLn "hi"
b = putStrLn "hi"
c = putStrLn "hi"
d = putStrLn "hi"
</pre><p>
Priority should maybe be set to high, since navigating source trees is simplified via the TAGS files.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1508#changelog
http://ghc.haskell.org/trac/ghc/ticket/1516
http://ghc.haskell.org/trac/ghc/ticket/1516#1516: Add Data.Stream, a library for manipulating infinite lists, to baseMon, 09 Jul 2007 18:03:07 GMTWouterSwierstra<p>
I'd propose to add a Data.Stream library to base. Data.Stream should be fairly uncontroversial. The module consists largely of a reimplimentation of several functions from Data.List to create, modify, and manipulate infinite lists. There is already a package on Hackage:
</p>
<p>
<a class="ext-link" href="http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Stream-0.1"><span class="icon"></span>http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Stream-0.1</a>
</p>
<p>
I've tried to include Haddock-comments, very similar to those for Data.List. As working with infinite lists can be tricky, I've included warnings clearly stating which functions can diverge.
</p>
<p>
I am aware that the name may cause confusion with Data.List.Stream. I'd welcome suggestions to avoid causing confusion.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1516#changelog
http://ghc.haskell.org/trac/ghc/ticket/1517
http://ghc.haskell.org/trac/ghc/ticket/1517#1517: Ratio Int is not well orderedMon, 09 Jul 2007 23:15:16 GMTdbenbenn@…<p>
Ratio Int is declared to be in class Ord, which means (according to <a class="ext-link" href="http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Ord.html#t%3AOrd"><span class="icon"></span>http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Ord.html#t%3AOrd</a>) that < should be a total ordering. Yet consider the following interactive session in GHCI (on a 32 bit computer!):
</p>
<pre class="wiki">Prelude> :m + Ratio
Prelude Ratio> let a = 1 % (2 :: Int)
Prelude Ratio> let b = 883177231 % (662415279 :: Int)
Prelude Ratio> let c = 1616076535 % (430549561 :: Int)
Prelude Ratio> a < b && b < c
True
Prelude Ratio> a < c
False
</pre><p>
The problem is that overflow occurs in Real.lhs (from the GHC source code), in the definition
</p>
<pre class="wiki">(x:%y) < (x':%y') = x * y' < x' * y
</pre><p>
That works for unbounded types (such as Integer). But to define a total order on bounded types, a more complicated method is necessary.
</p>
<p>
See <a class="ext-link" href="http://boost.cvs.sourceforge.net/boost/boost/boost/rational.hpp?revision=1.21&view=markup"><span class="icon"></span>http://boost.cvs.sourceforge.net/boost/boost/boost/rational.hpp?revision=1.21&view=markup</a>, line 374, for a correct implementation in C++.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1517#changelog
http://ghc.haskell.org/trac/ghc/ticket/1518
http://ghc.haskell.org/trac/ghc/ticket/1518#1518: Make it possible to evaluate monadic actions when assigning record fields (<-)Mon, 09 Jul 2007 23:20:21 GMTadde@…<p>
It is currently not possible to build records from values resulting from monadic actions while still using the field-specifiers.
</p>
<p>
foo :: IO Int
...
</p>
<p>
data Bar = Bar {
<dl class="wiki"><dt>barFoo</dt><dd>Int
</dd></dl>
}
</p>
<p>
buildBar :: IO ()
buildBar = do
</p>
<blockquote>
<p>
return Bar {
</p>
<blockquote>
<p>
barFoo <- foo --Evaluate foo to get the Int-value
</p>
</blockquote>
<p>
}
</p>
</blockquote>
<p>
I've found two possible ways of doing this:
</p>
<p>
1) Using temporaries to evaluate the actions before assigning which doubles the number of lines:
tmp <- foo
return Bar {
</p>
<blockquote>
<p>
barFoo = tmp
</p>
</blockquote>
<p>
}
</p>
<p>
2) Lifting the record constructor which prevents you from using field specifiers (and you really need field specifiers when dealing with larger records):
liftM Bar foo
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1518#changelog
http://ghc.haskell.org/trac/ghc/ticket/1520
http://ghc.haskell.org/trac/ghc/ticket/1520#1520: Use Linux's signalfd() instead of pipe() to deliver signals to the IO managerTue, 10 Jul 2007 07:36:33 GMTsimonmar<p>
As pointed out to me by dcoutts, Linux has a new API that enables signals and other events to be delivered via a file descriptor, and hence used with select()/poll()/epoll(). The new API went into Linux 2.6.22:
</p>
<p>
<a class="ext-link" href="http://kernelnewbies.org/Linux_2_6_22#head-0357b2415f5d3116bf2b03de07224d16912acec2"><span class="icon"></span>http://kernelnewbies.org/Linux_2_6_22#head-0357b2415f5d3116bf2b03de07224d16912acec2</a>
</p>
<p>
We could use this in GHC's IO manager to avoid the hacky use of pipe() for the same purpose.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1520#changelog
http://ghc.haskell.org/trac/ghc/ticket/1521
http://ghc.haskell.org/trac/ghc/ticket/1521#1521: Problems building the time library with Cabal / Setup.hsTue, 10 Jul 2007 15:27:23 GMTOlivier Boudry<p>
I get the following error when building the time library using ghc-6.6.1 and Cabal-1.1.6.2.
</p>
<pre class="wiki">C:\Temp\time>runhaskell Setup.hs configure
Setup.hs:17:29:
Couldn't match expected type `GHC.IOBase.ExitCode'
against inferred type `()'
Expected type: Args
-> Bool
-> PackageDescription
-> LocalBuildInfo
-> IO GHC.IOBase.ExitCode
Inferred type: Args
-> Bool
-> PackageDescription
-> LocalBuildInfo
-> IO ()
In the `runTests' field of a record
In the expression:
defaultUserHooks
{confHook = add_Win32_dep $ (confHook defaultUserHooks),
runTests = runTestScript}
</pre><p>
I solved it by changing the type signature of runTestScript and removing the maybeExit function call from the body:
</p>
<pre class="wiki">import GHC.IOBase
...
runTestScript :: Args -> Bool -> PackageDescription -> LocalBuildInfo -> IO GHC.IOBase.ExitCode
runTestScript _args _flag _pd _lbi
= withCurrentDirectory "test" $ system "make"
</pre><p>
Then, the Setup.hs script compiles but I get a dependency problem
</p>
<pre class="wiki">C:\Temp\time>runhaskell Setup.hs configure
Configuring time-1.1.1...
configure: Dependency Win32-any: using Win32-2.1.1
configure: Dependency base-any: using base-2.1.1
Setup.hs: cannot satisfy dependency old-locale-any
</pre><p>
I solved it with removing that dependency from the time.cabal file.
</p>
<p>
Last issue: at installation HsTimeConfig.h is missing (copied it from ghc-6.6.1 source).
</p>
<p>
I don't know to which extent those problems are related to my specific installation. Looks like the user hooks signature has changed in the latest versions of Cabal.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1521#changelog
http://ghc.haskell.org/trac/ghc/ticket/1539
http://ghc.haskell.org/trac/ghc/ticket/1539#1539: Ord should not default to ()Mon, 16 Jul 2007 12:54:03 GMTPeter Berry <pwberry@…><p>
See <a class="ext-link" href="http://hpaste.org/1711"><span class="icon"></span>http://hpaste.org/1711</a> . This defaulting is surprising and unuseful, since you can't define any interesting tests. The behaviour of GHC 6.6 (defaulting to Integer instead), or even not defaulting at all (e.g. by removing the monomorphism restriction or just not defaulting Ord), would be better.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1539#changelog
http://ghc.haskell.org/trac/ghc/ticket/1542
http://ghc.haskell.org/trac/ghc/ticket/1542#1542: Data/Time/Format/Parse cannot be compiled with -DDEBUGTue, 17 Jul 2007 13:19:42 GMTChristian.Maeder@…<pre class="wiki">../../compiler/ghc-inplace -O -fasm -DDEBUG -keep-s-files -keep-raw-s-files -Wall -Werror -fffi -Iinclude -package-name time-1.1.1 -O -Rghc-timing -fgenerics -package base -fgenerics -c Data/Time/Format/Parse.hs -o Data/Time/Format/Parse.o -ohi Data/Time/Format/Parse.hi
NOTE: Simplifier still going after 4 iterations; bailing out.
NOTE: Simplifier still going after 3 iterations; bailing out.
ghc-6.6.1: panic! (the 'impossible' happened)
(GHC version 6.6.1 for i386-apple-darwin):
ASSERT failed! file simplCore/Simplify.lhs line 541
[y{v s61y} [lid] [Just S] :: base:GHC.Num.Integer{tc 314}
[Str: DmdType]
y{v s61y} [lid] =
base:GHC.Num.plusInteger{v 0F} [gid]
(base:GHC.Num.timesInteger{v 0G} [gid]
lit_a1UF{v} [lid]
(base:GHC.List.poly_last'{v r1og} [gid]
@ base:GHC.Num.Integer{tc 314}
lit_a1S5{v} [lid]
(go{v s61t} [lid] cs{v s61h} [lid])))
(base:GHC.List.poly_last'{v r1og} [gid]
@ base:GHC.Num.Integer{tc 314}
lit_a1RW{v} [lid]
(go{v s61w} [lid] cs{v s61h} [lid]))]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
<<ghc: 594608812 bytes, 7 GCs, 4204804/8287284 avg/max bytes residency (2 samples), 294M in use, 0.00 INIT (0.00 elapsed), 1.67 MUT (2.09 elapsed), 0.10 GC (0.11 elapsed) :ghc>>
make[2]: *** [Data/Time/Format/Parse.o] Error 1
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/1542#changelog
http://ghc.haskell.org/trac/ghc/ticket/1543
http://ghc.haskell.org/trac/ghc/ticket/1543#1543: flag to define transpose [] == _|_Tue, 17 Jul 2007 22:10:34 GMTguest<p>
I use transpose a lot as an "unzip" function for lists. For example, suppose:
</p>
<pre class="wiki">foo :: [[String]]
</pre><p>
is a list of rows (say, of lenght 2) obtained from a SQL query. To transform it into a list of 2 columns, I simply write transpose foo. But, if foo is empty, I obtain... <a class="missing wiki">],[?</a>? No, I obtain []. I want the program to raise an error and stop, instead of (perhaps) produce a pattern match failure later, because transpose [] can arguably be [[]] or <a class="missing wiki">],[?</a> or <a class="missing wiki">],[],[?</a> or ... at least in some situations where it is used to "unzip" lists of lists.
</p>
<p>
I could use foo :: [(String, String)] or foo :: [(String, String, String)] etc., but [ [String]] is simpler and more general, and I can use map, etc.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1543#changelog
http://ghc.haskell.org/trac/ghc/ticket/1547
http://ghc.haskell.org/trac/ghc/ticket/1547#1547: Arity can decrease with -profWed, 18 Jul 2007 13:06:54 GMTigloo<p>
Something like
</p>
<pre class="wiki"> f = \p\q.body
x = scc "foo" f (\y.e)
</pre><p>
shows f having arity 2, and hence x having arity 1. But when we inline f, we get
</p>
<pre class="wiki"> x = scc "foo" let p = \x.e in \q.body
</pre><p>
and the cheap-and-cheerful arity discovery function (<tt>exprArity</tt>) detects arity of 0, not 1. And then CoreLint complains about the inconsistency of arity and strictness info.
</p>
<p>
This is unpleasant but not actually a problem.
</p>
<p>
It shows up in the <tt>conc052</tt> test (in the stm package).
</p>
<p>
Part of <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1546" title="bug: maessen_hashtab is broken (closed: fixed)">#1546</a> might be the same problem.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1547#changelog
http://ghc.haskell.org/trac/ghc/ticket/1554
http://ghc.haskell.org/trac/ghc/ticket/1554#1554: Ord (STRef s a) instanceSun, 22 Jul 2007 10:40:17 GMTiampure@…<p>
I would like an instance Ord (STRef s a). In the implementation this could be done with Data.Unique under the hood probably.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1554#changelog