November 2005 - Glasgow-haskell-users

Patch for Word64
by Matt 21 Nov '05

21 Nov '05

I was doing some work with Word64 and noticed that it was about 3 times slower than Int64. The reason appears to be expensive conversions from Int64# to Word64# and vice versa. I modified the libraries to remove the conversion overhead, and the result is that Int64# and Word64# now have equal performance, at least on the domain that I tested (==, +, -). I can't check into the tree, so I was told to send my changes to this list. Could someone else check them in? I have attached a patch file representing my changes. -Matt or [ricebowl, wearkilts, soysauce] on #haskell on Freenode

2 1

Broken build
by Dinko Tenev 20 Nov '05

20 Nov '05

I updated from HEAD recently, and got some strange error messages while building the stuff under libraries/X11: ../../ghc/compiler/ghc-inplace -H32m -O0 -W -fno-warn-unused-matches -fwarn-unused-imports -cpp -fffi -Iinclude -I/usr/X11R6/include -ignore-package X11 -O -dcore-lint -W -fno-warn-unused-matches -fwarn-unused-imports -keep-hc-files -package base -fgenerics -c Graphics/X11/Xlib/Font.hs -o Graphics/X11/Xlib/Font.o -ohi Graphics/X11/Xlib/Font.hi Font.hsc:70:0: Unacceptable argument type in foreign declaration: Display When checking declaration: foreign import ccall unsafe "static HsXlib.h &XQueryFont" queryFont :: Display -> Font -> IO FontStruct ...as well as several others for the same file, along the same lines. I am none the wiser by the messages, but the comment for ghc/compiler/prelude/TysWiredIn.lhs#rev1.75 seems to be related. Is this a regression? BTW, could someone give me a clue what the point is with a type like the one mentioned? Regards, Dinko

1 0

RE: Compiling GHC in Windows, Mingw
by Simon Marlow 18 Nov '05

18 Nov '05

On 17 November 2005 21:37, Esa Ilari Vuokko wrote: > On 11/17/05, Esa Ilari Vuokko <eivuokko(a)gmail.com> wrote: >> I will start a new clean build, hope it goes away and I need to look >> into buying non-broken hardware... ;) > > The build failed and I sent mail about it on cvs-ghc list this time, > even if something seemed to rip away my message and just leave > attachmenent.. > > Anyway, I downloaded few nightly builds and it seems this happens > with 11-17 build as well, but not with 11-16, so it's really recent. I think I have just fixed this (modification to the mangler in ghc/driver/mangler), please try again. Cheers, Simon

2 2

RE: Confusing Typing Problem
by Simon Peyton-Jones 18 Nov '05

18 Nov '05

Tricky! It certainly is confusing, but that's the way Hindley-Milner type inference for mutually recursive functions works. The local-defn version works differently because it - assumes a monomorphic type for f - completely typechecks g, including generalisation - finishes typechecking f That could be done if one typechecked the original defns in the "right" order, but it's not clear what the right order is. You specified the order by choosing which defn to nest. The other way round won't work g _ = f where f = A g Specifying a type sig should fix the problem, and does. | > a throw-away comment specifying that all explicit type signatures | > in a binding group must have the same context up to renaming of | variables | > [10,Section 4.5.2]. This is a syntactic restriction that can easily | > be checked prior to type checking. Our comments here, however, suggest | > that it is unnecessarily restrictive. | | Why does ghc still use that unnecessary restriction? It doesn't any more. The HEAD lifts the restriction; that'll be in GHC 6.6. Meanwhile you could try a snapshot build from the download site. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Bernd Brassel | Sent: 18 November 2005 10:16 | To: glasgow-haskell-users(a)haskell.org | Subject: Confusing Typing Problem | | I am a bit confused by GHC behaviour for the following variants of a | program: | | data A = A (Int -> A) | | f = A g | | g _ = f | | h = g 'c' | | ghc: | > Error: | > Couldn't match `Int' against `Char' | | The problem is that a small change ommits the error: | data A = A (Int -> A) | | f = A g | where | g _ = f | | h = g 'c' | | ghc: | > Ok, modules loaded | | But I really need the functions to be top-level, thus I added type | signatures: | data A = A (Int -> A) | | f :: A | f = A g | | g :: a -> A | g _ = f | | h :: A | h = g 'c' | | ghc: | > Ok, modules loaded | | Fine, but what I really need, is this: | | data A = A (Int -> A) | | f :: A | f = A g | | g :: Ord a => a -> A | g _ = f | | h :: A | h = g 'c' | | > Contexts differ in length | > The signature contexts in a mutually recursive group should all be | > identical | > ... | > Couldn't match `Int' against `Char' | | Again the problem does not occur for local functions: | | data A = A (Int -> A) | | f :: A | f = A g | where | g :: Ord a => a -> A | g _ = f | | h :: A | h = g 'c' | | Why is ghc treating local and global functions differently? Is there | really a difference in decidability of the Polymorphic Type Inference? | And regarding the "contexts differ in length", I read a comment in | "Typing Haskell in Haskell": | | > a throw-away comment specifying that all explicit type signatures | > in a binding group must have the same context up to renaming of | variables | > [10,Section 4.5.2]. This is a syntactic restriction that can easily | > be checked prior to type checking. Our comments here, however, suggest | > that it is unnecessarily restrictive. | | Why does ghc still use that unnecessary restriction? | | Cheers | Bernd | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-hask

1 0

RE: kind inference
by Simon Peyton-Jones 18 Nov '05

18 Nov '05

one could. but GHC doesn't. feels low prio to me... | -----Original Message----- | From: Ross Paterson [mailto:ross@soi.city.ac.uk] | Sent: 17 November 2005 12:45 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users(a)haskell.org | Subject: Re: kind inference | | On Thu, Nov 17, 2005 at 12:32:37PM -0000, Simon Peyton-Jones wrote: | > Yes it's deliberate. (Turned out to be easy and convenient.) Yes it | > goes beyond H98, so GHC types a few too many programs even in H98 mode. | > I guess I should document it. | | I think the H98 rule is arbitrarily restrictive. But what about going | further and considering the occurrences of type constructors in instance | declarations, type signature declarations and expression type signatures?

3 3

Confusing Typing Problem
by Bernd Brassel 18 Nov '05

18 Nov '05

I am a bit confused by GHC behaviour for the following variants of a program: data A = A (Int -> A) f = A g g _ = f h = g 'c' ghc: > Error: > Couldn't match `Int' against `Char' The problem is that a small change ommits the error: data A = A (Int -> A) f = A g where g _ = f h = g 'c' ghc: > Ok, modules loaded But I really need the functions to be top-level, thus I added type signatures: data A = A (Int -> A) f :: A f = A g g :: a -> A g _ = f h :: A h = g 'c' ghc: > Ok, modules loaded Fine, but what I really need, is this: data A = A (Int -> A) f :: A f = A g g :: Ord a => a -> A g _ = f h :: A h = g 'c' > Contexts differ in length > The signature contexts in a mutually recursive group should all be > identical > ... > Couldn't match `Int' against `Char' Again the problem does not occur for local functions: data A = A (Int -> A) f :: A f = A g where g :: Ord a => a -> A g _ = f h :: A h = g 'c' Why is ghc treating local and global functions differently? Is there really a difference in decidability of the Polymorphic Type Inference? And regarding the "contexts differ in length", I read a comment in "Typing Haskell in Haskell": > a throw-away comment specifying that all explicit type signatures > in a binding group must have the same context up to renaming of variables > [10,Section 4.5.2]. This is a syntactic restriction that can easily > be checked prior to type checking. Our comments here, however, suggest > that it is unnecessarily restrictive. Why does ghc still use that unnecessary restriction? Cheers Bernd

1 0

RE: Compiling GHC in Windows, Mingw
by Simon Marlow 17 Nov '05

17 Nov '05

On 17 November 2005 06:15, Esa Ilari Vuokko wrote: > I tried to compile ghc from cvs head in windows, hosting and > targetting mingw. When I got ghc to compile, it crashes while > parsing (I putStrLn-debugged) package.conf, but only from installed > position. > > Basically, somewhere inside ParsePkgConf.loadPackageConfig GHC crashes > with access violation. With very few test runs, it appears that > simplifying the file helps, but only case I got it not to crash was > one package in file, rts, and empty ldOptions. > > Maybe I went wrong somewhere, any pointers appreciated! > > What I did: > Current msys, msysdtk, binutils, win32api, gcc-core. > cvs checkout fpconfig and in there ghc, libraries, alex and happy > autoreconf > ./configure --host=i386-unknown-mingw32 > --with-gcc=d:/tools/msys/mingw/bin/gcc.exe > make > make install I haven't seen this, but I'm just updating my Windows build to try to reproduce. Does it happen with the stage1 or stage2 compiler? What version of GHC are you bootstrapping with? Cheers, Simon

2 2

RE: kind inference
by Simon Peyton-Jones 17 Nov '05

17 Nov '05

Yes it's deliberate. (Turned out to be easy and convenient.) Yes it goes beyond H98, so GHC types a few too many programs even in H98 mode. I guess I should document it. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Ross Paterson | Sent: 17 November 2005 11:31 | To: glasgow-haskell-users(a)haskell.org | Subject: kind inference | | The Haskell 98 Report says kind inference is to be done over dependency | groups with polymorphic kinds defaulted to *, and hence the following | example (from 4.6) is illegal: | | data Tree a = Leaf | Fork (Tree a) (Tree a) | | type TreeList = Tree [] | | GHC 6.4 seems to perform kind inference across all the data, newtype, | type and class declarations of a module before defaulting, and so accepts | the above. An improvement, I think, but unadvertised. Was it intentional? | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

kind inference
by Ross Paterson 17 Nov '05

17 Nov '05

The Haskell 98 Report says kind inference is to be done over dependency groups with polymorphic kinds defaulted to *, and hence the following example (from 4.6) is illegal: data Tree a = Leaf | Fork (Tree a) (Tree a) type TreeList = Tree [] GHC 6.4 seems to perform kind inference across all the data, newtype, type and class declarations of a module before defaulting, and so accepts the above. An improvement, I think, but unadvertised. Was it intentional?

1 0

Compiling GHC in Windows, Mingw
by Esa Ilari Vuokko 17 Nov '05

17 Nov '05

Hi! I tried to compile ghc from cvs head in windows, hosting and targetting mingw. When I got ghc to compile, it crashes while parsing (I putStrLn-debugged) package.conf, but only from installed position. Basically, somewhere inside ParsePkgConf.loadPackageConfig GHC crashes with access violation. With very few test runs, it appears that simplifying the file helps, but only case I got it not to crash was one package in file, rts, and empty ldOptions. Maybe I went wrong somewhere, any pointers appreciated! What I did: Current msys, msysdtk, binutils, win32api, gcc-core. cvs checkout fpconfig and in there ghc, libraries, alex and happy autoreconf ./configure --host=i386-unknown-mingw32 --with-gcc=d:/tools/msys/mingw/bin/gcc.exe make make install (I had to change some things, as described on mail to bugs-list, so few repeated make's) I will try clean rebuild later, but I feel doubtful. Best regards, --Esa

1 0