- Glasgow-haskell-users

os x 64-bit?
by John Lato 11 Nov '10

11 Nov '10

Hello, I was wondering if there is a status report anywhere of progress towards making ghc compile 64-bit on Snow Leopard. There are a few trac tickets that seem related: 4263: http://hackage.haskell.org/trac/ghc/ticket/4163 2965: (not sure, trac says the database is locked when I try to look at this one) Is Ian working on this, or anyone else? I'd like to help if I can, and I was wondering where would be the best place to start? I probably won't actually contribute much, but this seems as good a way as any for me to start working with ghc. Cheers, John

4 4

Loop optimisation with identical counters
by Christian Höner zu Siederdissen 10 Nov '10

10 Nov '10

Hi, is the following problem a job for ghc or the code generation backend (llvm)? We are given this program: {-# LANGUAGE BangPatterns #-} module Main where f :: Int -> Int -> Int -> Int -> Int f !i !j !s !m | i == 0 = s+m | otherwise = f (i-1) (j-1) (s + i+1) (m + j*5) g :: Int -> Int g !k = f k k 0 0 ff :: Int -> Int -> Int -> Int ff !i !s !m | i == 0 = s+m | otherwise = ff (i-1) (s + i+1) (m + i*5) gg :: Int -> Int gg !k = ff k 0 0 main = do print $ g 20 print $ gg 20 Here, 'f' and 'g' are a representation of the code I have. Both counters 'i' and 'j' in 'f' count from the same value with the same step size and terminate at the same time but are not reduced to just one counter. Can I reasonably expect this to be done by the code generator? 'ff' represents what I would like to see. Btw. look at the core, to see that indeed 'f' keep four arguments. Functions like 'f' are a result of vector-fusion at work but can be written by oneself as well. The point is that if 'f' gets reduced to 'ff' then I can have this: fun k = zipWith (+) (map f1 $ mkIdxs k) (map f2 $ mkIdxs k) which makes for nicer code sometimes; but before rewriting I wanted to ask if that kills performance. Thanks, Christian

9 20

Wadler space leak
by Jan Christiansen 09 Nov '10

09 Nov '10

Hi, I have a question regarding the famous Wadler space leak. The following program is a variation of Wadler's example. let (first,rest) = break (const False) input in print (length (first ++ rest)) When I compile this program using -O2 and use a large text file as input the code runs in constant space. If I understand correctly, the program runs in constant space because ghc uses an optimization similar to the one proposed by Wadler/Sparud. If I define the following function which is based on break splitBy :: (a -> Bool) -> [a] -> [[a]] splitBy _ [] = [] splitBy p xs = l : case ys of [] -> [] _:zs -> splitBy' p zs where (l,ys) = break p xs and compile the following program the behaviour is different. print (length (concat (splitBy (const False) input))) In this case the memory usage is not constant. However if I use a strict pattern matching instead of the lazy tuple matching the program runs in constant space. splitBy' :: (a -> Bool) -> [a] -> [[a]] splitBy' _ [] = [] splitBy' p xs = case break p xs of (l,ys) -> l : case ys of [] -> [] _:zs -> splitBy p zs To me this looks like another instance of the Wadler space leak. Is this correct? I do not understand why the Wadler example runs in constant space and this example does not. Can anyone explain me why these functions behave differently? I still get the same behaviour if I use the following simplified function. test :: (a -> Bool) -> [a] -> [[a]] test _ [] = [] test p xs = l : case ys of [] -> [] where (l,ys) = break p xs That is, the following program does not run in constant space. print (length (concat (test (const False) input))) On a related note if I do not use -O2 the following program runs in constant space let (first,rest) = break (const False) input in print (length (first ++ rest)) while it does not run in constant space if I add an application of id as follows. let (first,rest) = break (const False) input in print (length (first ++ id rest)) Thanks, Jan

6 9

Re: change in overlapping instance behavior between GHC 6.12 and GHC 7 causes compilation failure
by Jeremy Shaw 09 Nov '10

09 Nov '10

Hello, I have narrowed this down further to a single file. And created a trac bug for it: http://hackage.haskell.org/trac/ghc/ticket/4485 This is (the only thing?) holding up HSP and happstack moving to GHC 7. - jeremy On Tue, Nov 2, 2010 at 5:36 PM, Jeremy Shaw <jeremy(a)n-heptane.com> wrote: > Hello, > > I have a module, XMLGenerator, which has some overlapping instances. > I have a second module, Test, which imports that module and also adds > some more overlapping instances. > > Both modules contain {-# LANGUAGE OverlappingInstances #-} at the top. > > Under some old version of 6.13 (and probably 6.12), if I put both > modules in the same directory and try to load Test.hs, it gets the > error: > > Test.hs:16:15: > Overlapping instances for EmbedAsChild (M IO) (XMLGenT m (XML m)) > arising from a use of `asChild' at Test.hs:16:15-21 > Matching instances: > instance (m1 ~ m, EmbedAsChild m c) => > EmbedAsChild m (XMLGenT m1 c) > -- Defined at XMLGenerator.hs:16:10-68 > instance (XML m ~ x, XMLGen m) => EmbedAsChild m x > -- Defined at XMLGenerator.hs:19:10-51 > In the first argument of `($)', namely `asChild' > In the expression: asChild $ (genElement "foo") > In the definition of `asChild': > asChild b = asChild $ (genElement "foo") > > If I put the XMLGenerator module in a separate package, dummy-hsx, and > the Test modules links against it, I still get the error. > > *but* if I add: > > Extensions: OverlappingInstances > > to the dummy-hsx.cabal file, then Test.hs compiles just fine! So, for > starters, I do not understand why that happens. > > Under GHC 7.0rc1, modifying the .cabal file has no effect. Instead I > always get the error: > > Test.hs:16:15: > Overlapping instances for EmbedAsChild (M IO) (XMLGenT m (XML m)) > arising from a use of `asChild' > Matching instances: > instance [overlap ok] (m1 ~ m, EmbedAsChild m c) => > EmbedAsChild m (XMLGenT m1 c) > -- Defined in XMLGenerator > (The choice depends on the instantiation of `m' > To pick the first instance above, use -XIncoherentInstances > when compiling the other instance declarations) > > Adding the IncoherentInstances flag does make it compile -- but I have > never enabled that flag and not regretted it. > > What changed between GHC 6.12 and GHC 7.0? Is there a some solution > besides using IncoherentInstances in every module that imports > XMLGenerator? > > I have attached XMLGenerator.hs, Test.hs, and dummy-hsx.cabal. > > thanks! > - jeremy >

3 3

ANNOUNCE: GHC 7.0.1 Release Candidate 2
by Ian Lynagh 09 Nov '10

09 Nov '10

We are pleased to announce the second release candidate for GHC 7.0.1: http://new-www.haskell.org/ghc/dist/7.0.1-rc2/ This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. Amongst the changes since RC 1 are: * -fglasgow-exts now gives a deprecated warning, and no longer enables GADTs or TypeFamilies. * The haskell98 packge is no longer automatically linked, although this often won't make a difference as --make is now enabled by default. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team

5 6

new-www
by Serge D. Mechveliani 09 Nov '10

09 Nov '10

People, what is, in short, the relation between www.haskell.org and new-www.haskell.org ? Which one do I need to use for looking for the Haskell materials, for GHC materials? Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2

Re: Loop optimisation with identical counters
by christian Hoener zu Siederdissen 07 Nov '10

07 Nov '10

Yes indeed, this is what some fusion code could look like. I deal with stuff like this: mk i j = enumFromN (i+1) (j-i-2) -- gen indices, sometimes index pairs f i j k = T!(i,k) + T!(k+1,j) -- table lookup using some 2d tables g i j k = fun i k + fun (k+1) j -- some funny calculation z i j = minimum $ zipWith (+) (map (f i j) $ mk i j) (map (g i j) $ mk i j) y i j = minimum (map (g i j) $ mk i j) So i would like to split my calculations into f and g as sometimes (in backtracking results) only g is needed. Furthermore, there are like 12 different f g z y mk each. Being able to seperate the worker into f g means cleaner code and that it is easier to change stuff. Note that mk in f is always called with the same borders, leading to things like my original problem. But Roman has already pointed out how often this duplication of counters can occur. Gruss, Christian PS: above is a bit pseudocode-like but captures the essentials and my thumbs are numb now... ;-) ----- Original message ----- > On 06/11/2010, at 02:27, Sebastian Fischer wrote: > > > Interesting. This approach requires `f` to be inlined into its call > > site in order to eliminate the redundant argument. This is different > > from the proposal to provide a specialized version of `f` (where the > > arguments are combined) which could be reused at different call sites. > > Which proposal do you mean? I'm not sure something like that is feasible > without knowing the call sites. You have to know which arguments to > combine. > > > How many call sites with identical arguments are there in the > > generated code that triggered this discussion and in the stream fusion > > code that would benefit from this optimization? > > In stream fusion code, there is normally exactly one call site. I > suspect that the Christian's example has also been derived from stream > fusion code. > > Roman > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Rigid types fun
by Mitar 06 Nov '10

06 Nov '10

Hi! I have much fun with rigid types, type signatures and GADTs. And I would like to invite also others in and share my joy. ;-) Please see the attached file and chase a solution to how to make it compile. I would like to have a function which I would call like: createNerve (Axon undefined) (AxonAny undefined) and it would return proper Nerve. Similar to how asTypeOf works. I would like to do that to remove repeating code like: from <- newChan for <- newChan let nerve = Nerve (Axon from) (AxonAny for) which I have to write again and again just to make types work out. Why I cannot move that into the function? I am using GHC 6.12.3. Is this something which will work in 7.0? Mitar

3 6

Unicode windows console output.
by David Sankel 05 Nov '10

05 Nov '10

Hello all, I'm attempting to output some Unicode on the windows console. I set my windows console code page to utf-8 using "chcp 65001". The program: -- Test.hs main = putStr "λ.x→x" The output of `runghc Test.hs`: λ.x→xxxx >From within ghci, typing `main`: λ*** Exception: <stdout>: hPutChar: permission denied (Permission denied) I suspect both of these outputs are evidence of bugs. Might I be doing something wrong? (aside from using windows ;)) TIA, David -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)

5 10

Re: link problem under macosx
by John Lato 04 Nov '10

04 Nov '10

> > From: Simon Michael <simon(a)joyful.com> > > On 11/2/10 10:20 AM, John Lato wrote: > > Since Apple seems disinclined to fix the system's libiconv, and macports > projects refuse to use it, the only real > > solution is to use either HP without macports or the macports GHC without > HP. Personally I chose to use the HP and > > Not so, as mentioned you just need to make sure /usr/lib is in the link > path before /opt/local/lib. Add -L/usr/lib to > your build flags for ghc --make, and put: > > extra-lib-dirs: /usr/lib > extra-lib-dirs: /opt/local/lib > > in that order in ~/.cabal/config for cabal build. > > This is a very FAQ and needs to be documented somewhere more obvious, I > wonder where. cabal-install and GHC release notes ? > As I mentioned in another reply, this worked for me until I tried to link to a macports lib (I think some regex lib) that actually used the macports libiconv (a lot of them don't even if they pull in the dependency). Then I was really stuck because I had dependencies on two different libiconv's, and neither one would link properly. As such, I consider this a pretty fragile "solution". John

2 1