March 2009 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

ANNOUNCE: GHC 6.8.3 Release Candidate
by Ian Lynagh 22 Sep '09

22 Sep '09

We are pleased to announce the Release Candidate phase for GHC 6.8.3. Snapshots beginning with 6.8.2.20080527 are release candidates for 6.8.3 You can download snapshots from here: http://www.haskell.org/ghc/dist/stable/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src-extralib… Only the first of these is necessary. The "extralibs" package contains various extra packages that are often supplied with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There is also currently an installer for i386/Windows and binary distributions for x86_64/Linux and i386/Linux. More may appear later. Please test as much as possible; bugs are much cheaper if we find them before the release! We expect to release in a few days, assuming no major issues are discovered. Thanks Ian, on behalf of the GHC team

8 13

Linking and constants problems with OpenAL under Windows
by Jared 02 May '09

02 May '09

The OpenAL binding's wiki page directs questions to Haskell-Cafe, but the more serious of my problems seems to be with GHC. My platform is GHC 6.10.1 under Windows XP. This post boils down to two questions. First, why would GHCi and GHC look for different symbol names when linking, and second, has anybody had any success working with the OpenAL binding on Windows? If I write a program that uses Sound.OpenAL, I can load and run it in GHCi. If I try to compile the same program with ghc --make -lopenal32 audio.hs, I get a raft of errors like this: Linking audio.exe ... C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.10.1/libHSOpenAL-1.3.1.1.a(BufferInternal.o):fake:(.text+0x5d): undefined reference to `alIsBuffer' C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.10.1/libHSOpenAL-1.3.1.1.a(Context.o):fake:(.text+0x7d): undefined reference to `alcGetContextsDevice' C:\Program Files\Haskell\OpenAL-1.3.1.1\ghc-6.10.1/libHSOpenAL-1.3.1.1.a(Context.o):fake:(.text+0xcd): undefined reference to `alcMakeContextCurrent' The names do not exist in openal32.lib. They should all be preceded by an underscore. GHC does the same thing if I convert the .lib file to a .a file. But why would GHCi do the right thing and GHC do the wrong thing? Am I missing a command line switch? I manually changed configure and configure.ac, per the patches (why weren't those applied to the library in Hackage?) to use ccall since OpenAL uses ccall instead of stdcall. Was there another change I should have made? The other problem is that several routines don't work properly because the constants don't get fixed up correctly during the build process. For example, the function marshalFormat in Sound.OpenAL.AL.Format should return 0x1100 when given Word8 as a parameter. It returns -1 instead; the code tells it to, but I assume some sed-like command was supposed to patch that with the right value. Has anybody had any luck getting this to work?

2 1

Unable to compile ghc from darcs
by Colin Paul Adams 01 Apr '09

01 Apr '09

I was getting errors somewhere in haddock about some ambiguous function, so I did a darcs pull to see if that would pull in a fix for the problem (unfortunately I didn't make a note of the errors). But now the compile fails earlier with errors in deSugar/DsMeta.hs: deSugar/DsMeta.hs:471:48: Not in scope: type constructor or class `TH.InlineSpecQ' deSugar/DsMeta.hs:504:16: Not in scope: type constructor or class `TH.TyVarBndr' deSugar/DsMeta.hs:538:50: Not in scope: type constructor or class `TH.TyVarBndr' deSugar/DsMeta.hs:640:29: Not in scope: type constructor or class `TH.Kind' etc. Is the code in darcs supposed to be compilable normally? And what can I do about such situations? Just report them here? -- Colin Adams Preston Lancashire

5 22

GADTs with strict fields?
by Conal Elliott 01 Apr '09

01 Apr '09

Do strict fields work with GADTs? If so, what's the syntax for the strictness annotations? - Conal

2 2

spurious "non-exhaustive" pattern warnings?
by Conal Elliott 31 Mar '09

31 Mar '09

-- Why do I get warnings about non-exhaustive pattern matches in the -- following code? Is the compiler just not clever enough to notice that -- the uncovered cases are all type-incorrect? (ghc 6.11.20090115) {-# LANGUAGE TypeFamilies, EmptyDataDecls, TypeOperators , GADTs, KindSignatures , FlexibleInstances, FlexibleContexts #-} {-# OPTIONS_GHC -Wall #-} import Control.Applicative (Applicative(..)) data Z data S n infixr 1 :< data Vec :: * -> * -> * where ZVec :: Vec Z a (:<) :: a -> Vec n a -> Vec (S n) a -- todo: infix op for SVec instance Functor (Vec n) where fmap _ ZVec = ZVec fmap f (a :< u) = f a :< fmap f u instance Applicative (Vec Z) where pure _ = ZVec ZVec <*> ZVec = ZVec -- Warning: Pattern match(es) are non-exhaustive -- In the definition of `<*>': -- Patterns not matched: -- (_ :< _) _ -- ZVec (_ :< _) instance Applicative (Vec n) => Applicative (Vec (S n)) where pure a = a :< pure a (f :< fs) <*> (x :< xs) = f x :< (fs <*> xs) -- Warning: Pattern match(es) are non-exhaustive -- In the definition of `<*>': -- Patterns not matched: -- ZVec _ -- (_ :< _) ZVec

2 1

Control.Parallel.Strategies.parMap CPU usage
by Christian Hoener zu Siederdissen 30 Mar '09

30 Mar '09

Greetings, when using parMap (or parList and demanding) I see a curious pattern in CPU usage. Running "parMap rnf fib [1..100]" gives the following pattern of used CPUs: 4,3,2,1,4,3,2,1,... The fib function requires roughly two times the time if we go from fib(n) to fib(n+1), meaning that calculating the next element in the list always takes longer than the current. What I would like is a version of parMap that directly takes a free CPU and lets it calculate the next result, giving the usage pattern 4,4,4,4,... Below you find the simple Haskell program, which gives these results, please compile with "ghc --make -threaded -O2 Para.hs" and run on a machine with at least two cores and "./Para +RTS -N2" or better. I am not filing a bug yet as I would prefer to be told that I did it wrong and here is a better way: ... Thanks, Christian (Please assume that later on, "fib" will be replaced by something meaningful ;) # ghc --version # The Glorious Glasgow Haskell Compilation System, version 6.10.1 module Main where import Control.Parallel.Strategies -- parallel computation of fibonacci numbers in slow fib :: Int -> Int fib n | n < 1 = error "n < 1" | n == 1 = 1 | n == 2 = 1 | otherwise = fib (n-1) + fib(n-2) fibs = parMap rnf fib $ [1..100] -- fibs = let fs = map fib $ [1..100] in fs `demanding` (parList rnf fs) main = do mapM_ (putStrLn . show) $ zip [1..] fibs

4 5

copyFile and thread safety
by Neil Mitchell 30 Mar '09

30 Mar '09

Hi, Using GHC 6.8.3, the copyFile routine isn't thread safe - it crashes when two threads try and open the same file. I think that improvements were made to avoid security race conditions in GHC 6.10.1 (or the base library associated with it), and as a nice side effect they seem to have fixed the copyFile issues. However, it would be nice if someone could assure me that the copyFile issues were real but are now fixed. Replicating them is hard, but they randomly occur during a 1-hour build on my laptop, but not my desktop. I also note that copyFile starts with the process id and increments looking for a free filename. While that's fantastic if you are avoiding races with other processes (as I think the improvements were intended to address), it's not so great for avoiding races within the same process when different threads attempt to copy lots of files at once. In doing this, I suspect I've suffered lots of retries in the temporary name creation algorithm - should I be concerned about the performance aspect of this? Would an atomicModifyIORef and global temp file counter be a good idea? For now, I've got no immediate problems as I simply shell out to "cp" to do the copying - but it would be nice if the Haskell worked too. Thanks Neil

1 0

Few problems with building GHC
by Zachary Turner 30 Mar '09

30 Mar '09

Hi, This is my first time trying to compile GHC, so forgive me if these issues are mentioned somewhere. I couldn't find them anywhere on the wiki. First, I had originally installed a binary distribution and then tried to compile another program (a Haskell editor) that recommended I have source available for all libraries, since it would be able to give me better info in the editor. So this is why I decided to compile GHC from source in the first place. So I compiled GHC, and did make install, and I was _expecting_ that all of the library sources would end up in the directories alongside the binaries as well and that this is how the editor would be able to locate the source. But this did not happen, and instead my library folders look exactly like they do in the binary distribution that I installed by downloading the prepacked installer from the website. However, at one point I had downloaded some packages from Hackage and installed them with runhaskell configure, runhaskell build, runhaskell install on each of these new libraries, and the source did end up in the library directories alongside the binaries. So I feel like I'm doing something wrong in building GHC, and that when I install there should be a way to have the source of the libraries copied to the target directories. Can someone elaborate on how this is supposed to work for other programs that depend on the library sources to be able to find them? I know that of the 2 Hackage packages that I installed, the editor printed a message saying that it did find source for those two, but not for any other libraries. Second, I cannot create a windows build of GHC under cygwin. Looking at the Building Guide on the wiki suggests that this is indeed supported. However, when I try to build it I get cabal-bin.exe: Cannot find the program 'ghc' at '/cygdrive/c/dev/haskell/ghc/ghc-6.10.1/bin/ghc' or on the path make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving directory `/cygdrive/c/dev/haskell/ghc/ghc-6.10.1-src/libraries' make: *** [stage1] Error 2 There seems to be some unix/windows confusion here, because it's looking for an executable file named "ghc", when the actual executable name is "ghc.exe". However, building under MSYS everything works perfectly. Is Cygwin just not supported, or do I need to change something here? I don't see any point in cluttering up my system with tons of extra software like MinGW, msys, etc if Cygwin works fine. Last, after building GHC when I go to run make install, I want the target location to be the original location of the compiler that I used to build GHC in the beginning. In other words, I want to have it overwrite the old version of GHC instead of going to the default install location under /usr/bin, etc... How can I specify the target install location?

2 3

Loop unrolling + fusion ?
by Don Stewart 27 Mar '09

27 Mar '09

Hey guys, We have nice fusion frameworks now. E.g. stream fusion on uvector, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uvector Takes something like this: import Data.Array.Vector import Data.Bits main = print . productU . mapU (*2) . mapU (`shiftL` 2) $ replicateU (100000000 :: Int) (5::Int) and turns it into a loop like this: $wfold :: Int# -> Int# -> Int# $wfold = \ (ww_sWX :: Int#) (ww1_sX1 :: Int#) -> case ww1_sX1 of wild_B1 { __DEFAULT -> $wfold (*# ww_sWX 40) (+# wild_B1 1); 100000000 -> ww_sWX } Now, that's fine in my book. Going via -fasm, we get: Main_zdwfold_info: .LcYt: movq %rdi,%rax cmpq $100000000,%rax jne .LcYx movq %rsi,%rbx jmp *(%rbp) .LcYx: incq %rax imulq $40,%rsi movq %rax,%rdi jmp Main_zdwfold_info Ok: $ time ./product 0 ./product 0.31s user 0.00s system 96% cpu 0.316 total Going via C, however, we get: Main_zdwfold_info: cmpq $100000000, %rdi je .L6 .L2: leaq (%rsi,%rsi,4), %rax leaq 1(%rdi), %rdi leaq 0(,%rax,8), %rsi jmp Main_zdwfold_info Nice! $ time ./product 0 ./product 0.19s user 0.00s system 97% cpu 0.197 total So now, since we've gone to such effort to produce a tiny loop like, this, can't we unroll it just a little? Sadly, my attempts to get GCC to trigger its loop unroller on this guy haven't succeeded. -funroll-loops and -funroll-all-loops doesn't touch it, Anyone think of a way to apply Claus' TH unroller, or somehow convince GCC it is worth unrolling this guy, so we get the win of both aggressive high level fusion, and aggressive low level loop optimisations? -- Don

9 33