November 2006 - Glasgow-haskell-users

ghc threaded1 test-cases under Solaris
by Christian Maeder 10 Nov '06

10 Nov '06

Hi, when running the test-suite I get plenty of the link errors (below). In order to resolve the missing symbols in Printer.thr_debug_o I was able to add -optl-L/usr/local/lib -optl-lbfd -optl-liberty to the ghc-6.6 command line. Note that "-L/usr/local/lib" is necessary, because otherwise the wrong libiberty.a file is found (namely that of gcc with a missing symbol "unlink_if_ordinary"). I don't know how to build this properly into the compiler (or a configure script). Cheers Christian /home/maeder/haskell/solaris/ghc-6.6/rts/libHSrts_thr_debug.a(Printer.thr_debug_ o): In function `DEBUG_LoadSymbols': /home/maeder/haskell/solaris/ghc-6.6/rts/Printer.c:997:0: undefined reference to `bfd_init' /home/maeder/haskell/solaris/ghc-6.6/rts/Printer.c:998:0: undefined reference to `bfd_openr' /home/maeder/haskell/solaris/ghc-6.6/rts/Printer.c:1002:0: undefined reference to `bfd_check_format_matches' collect2: ld returned 1 exit status

1 1

RE: [Haskell] Deferred instance declarations (serialization ofexistential boxes)
by Simon Peyton-Jones 10 Nov '06

10 Nov '06

[redirecting to GHC users, since it's a GHC-specific question] Misha | I asked this question on haskell-cafe once, but my post didn't get any | responses, so I try once again here explaining a bit more where my | problem comes from. I was at ICFP. | Suppose I have a monomorphic datatype, say T and want to do something | with it, which depends on an instance of class C being defined for T. | However I can only provide this instance later, in a different module. | So I would like to write something like | | > f :: C T => T -> T | or | > instance C T => C T' where | > -- a body that uses functions from C T There is no reason in principle why this isn't ok. But there is a practical reason why things are the way they are. Generally, GHC tries to share constraints as much as possible, so that a (C T) constraint in one function right hand side is satisfied by the same binding as another (C T) constraint from another right hand side. So in general, GHC "floats" constraints outwards if they don't mention any type variables bound by the forall's of the type signature. The whole question of the interaction of type signatures and constraints is quite delicate, and I rather doubt I'll change this behaviour soon. (And no one else has asked for it before, I think.) But I think the case is stronger for top-level constraints, and I will bear it in mind. If you would like to open a Trac feature request, please do so. Concerning your application | I am having a box like | > data Box = forall a. Cxt a => Box a | and want to write a Read instances for it. I don’t see how it helps to defer the Read instance. Reading existentials is bound to be difficult, or even impossible. I guess it depends what is in Cxt. Simon

2 2

subtle inlining problem
by Bulat Ziganshin 09 Nov '06

09 Nov '06

Hello glasgow-haskell-users, in the following definitions: > {-# INLINE getInteger #-} > getInteger = ... -- large definition that will be not inlined > -- without pragma > > instance Binary Integer where > get = getInteger is Integer.get will be inlined or not? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 4

Desugaring overloaded functions
by Bas van Dijk 08 Nov '06

08 Nov '06

Dear GHC Hackers, I'm using the GHC API for a project of mine. I have a question about the way GHC 'desugars' the following overloaded function: incL :: (Num a) => [a] -> [a] incL [] = [] incL (x : xs) = (1 + x) : (incL xs) After calling 'Desugar.deSugar' on this function I get the following Core representation: Test.incL = \ (@ a_ag0) ($dNum_al8 :: {GHC.Num.Num a_ag0}) -> __letrec { incL_afU :: [a_ag0] -> [a_ag0] incL_afU = \ (ds_dlZ :: [a_ag0]) -> case ds_dlZ of wild_B1 { [] -> __letrec { } in GHC.Base.[] @ a_ag0; : x_adm xs_adn -> __letrec { } in GHC.Base.: @ a_ag0 (+_al3 lit_al2 x_adm) (incL_afU xs_adn) }; $dNum_alp :: {GHC.Num.Num a_ag0} $dNum_alp = $dNum_al8; fromInteger_alm :: GHC.Num.Integer -> a_ag0 fromInteger_alm = GHC.Num.fromInteger @ a_ag0 $dNum_alp; lit_al2 :: a_ag0 lit_al2 = fromInteger_alm (GHC.Num.S# 1); +_al3 :: a_ag0 -> a_ag0 -> a_ag0 +_al3 = GHC.Num.+ @ a_ag0 $dNum_al8; } in incL_afU; This is great! However, I don't understand why: 'incL_afU', '$dNum_alp', 'fromInteger_alm', 'lit_al2' and '+_al3' are all listed under the same letrec? What I expect is that a dependency analysis is also applied to this letrec resulting in something like: Test.incL = \ (@ a_ag0) ($dNum_al8 :: {GHC.Num.Num a_ag0}) -> let $dNum_alp :: {GHC.Num.Num a_ag0} $dNum_alp = $dNum_al8; in ( let +_al3 :: a_ag0 -> a_ag0 -> a_ag0 +_al3 = GHC.Num.+ @ a_ag0 $dNum_al8; in ( let fromInteger_alm :: GHC.Num.Integer -> a_ag0 fromInteger_alm = GHC.Num.fromInteger @ a_ag0 $dNum_alp; in ( let lit_al2 :: a_ag0 lit_al2 = fromInteger_alm (GHC.Num.S# 1); in ( __letrec { incL_afU :: [a_ag0] -> [a_ag0] incL_afU = \ (ds_dlZ :: [a_ag0]) -> case ds_dlZ of wild_B1 { [] -> __letrec { } in GHC.Base.[] @ a_ag0; : x_adm xs_adn -> __letrec { } in GHC.Base.: @ a_ag0 (+_al3 lit_al2 x_adm) (incL_afU xs_adn) }; } in incL_afU; ) ) ) ) I would really like the output of 'Desugar.deSugar' to be like the latter. Because than I can apply some beta-reductions to get rid of the non-recursive lets and use that as input for the rest of my project... So, why isn't a dependency analysis applied to the letrec? And is it possible to manually apply a dependency analysis? If so, where can I find such a function? Many thanks in advance, Bas van Dijk P.S. I know that applying 'SimplCore.core2core' will result in something that I almost want: [Test.incL :: forall a_ad8. (GHC.Num.Num a_ad8) => [a_ad8] -> [a_ad8] Test.incL = \ (@ a_akG) ($dNum_akS :: {GHC.Num.Num a_akG}) -> let { lit_akM :: a_akG lit_akM = case $dNum_akS of tpl_Xb { GHC.Num.:DNum tpl_B2 tpl_B3 tpl_B4 tpl_B5 tpl_B6 tpl_B7 tpl_B8 tpl_B9 tpl_Ba -> tpl_Ba (GHC.Num.S# 1) } } in __letrec { incL_akH [LoopBreaker Nothing] :: [a_akG] -> [a_akG] incL_akH = \ (ds_dle :: [a_akG]) -> case ds_dle of wild_B1 { [] -> GHC.Base.[] @ a_akG; : x_adb xs_adc -> GHC.Base.: @ a_akG (case $dNum_akS of tpl_X9 { GHC.Num.:DNum tpl_B2 tpl_B3 tpl_B4 tpl_B5 tpl_B6 tpl_B7 tpl_B8 tpl_B9 tpl_Ba -> tpl_B4 lit_akM x_adb }) (incL_akH xs_adc) }; } in incL_akH] However the rest of my project has trouble with the way 'fromInteger_alm' and '+_al3' are optimzed to case-expressions. So I would rather not use 'core2core'.

2 4

Link error under solaris 8
by Christian Maeder 08 Nov '06

08 Nov '06

Hi, I get a link error under sparc sun Solaris 8, when linking my stage2 compiler. I have "undefined reference to" a couple of mathematical function like powf, tanhf, coshf, sinhf, atanf, acosf, asinf, tanf, cosf, sinf, sqrtf, logf, and expf Is libm version 2 needed? The stage1 compiler was content with libm version 1. Cheers Christian -bash-3.00$ uname -a SunOS euklid 5.8 Generic_117350-41 sun4u sparc SUNW,Ultra-4 -bash-3.00$ ldd compiler/stage1/ghc-6.6 libdl.so.1 => /usr/lib/libdl.so.1 libm.so.1 => /usr/lib/libm.so.1 libgmp.so.3 => /usr/local/lib/libgmp.so.3 libc.so.1 => /usr/lib/libc.so.1 /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1 ../compiler/stage1/ghc-inplace -o stage2/ghc-6.6 -H16m -O -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -DBREAKPOINT -threaded stage2/main/Main.o /home/maeder/haskell/solaris/ghc-6.6/libraries/base/libHSbase.a(Float__151.o): In function `s9W7_info': ghc29001_0.hc:(.text+0x290): undefined reference to `powf' /home/maeder/haskell/solaris/ghc-6.6/libraries/base/libHSbase.a(Float__152.o): In function `s9Wv_info': ghc29001_0.hc:(.text+0x28c): undefined reference to `tanhf' /home/maeder/haskell/solaris/ghc-6.6/libraries/base/libHSbase.a(Float__153.o): In function `s9WK_info': ghc29001_0.hc:(.text+0x288): undefined reference to `coshf' /home/maeder/haskell/solaris/ghc-6.6/libraries/base/libHSbase.a(Float__154.o): In function `s9WZ_info': ghc29001_0.hc:(.text+0x288): undefined reference to `sinhf' [...] /home/maeder/haskell/solaris/ghc-6.6/libraries/base/libHSbase.a(Float__237.o): In function `s85X_info': ghc29001_0.hc:(.text+0x974): undefined reference to `atanf' collect2: ld returned 1 exit status <<ghc: 19353284 bytes, 3 GCs, 100700/100700 avg/max bytes residency (1 samples), 15M in use, 0.01 INIT (0.00 elapsed), 0.33 MUT (34.47 elapsed), 0.03 GC (0.09 elapsed) :ghc>> gmake[3]: *** [stage2/ghc-6.6] Error 1 gmake[3]: Leaving directory `/home/maeder/haskell/solaris/ghc-6.6/compiler' gmake[2]: *** [stage2/ghc-6.6] Error 2 gmake[2]: Leaving directory `/home/maeder/haskell/solaris/ghc-6.6/compiler' gmake[1]: *** [stage2] Error 2 gmake[1]: Leaving directory `/home/maeder/haskell/solaris/ghc-6.6' gmake: *** [bootstrap2] Error 2

1 1

Parallelism in 6.6 and seq vs. pseq
by Simon Marlow 08 Nov '06

08 Nov '06

I just noticed, thanks to some testing of the parallelism support in 6.6 by Satnam Singh, that Control.Parallel exports seq when in fact it should probably export pseq. The difference is subtle. The semantics of seq and pseq are identical; however, GHC can see that seq is strict in both its arguments and hence could choose to evaluate them in either order, whereas pseq is only strict in its first argument as far as the strictness analyser is concerned. The point is that pseq is useful for controlling evaluation order, which is what you want for adding parallelism to a program. seq, on the other hand, is not useful for controlling evaluation order. The documentation in 6.6 is also incorrect on this point. pseq is currently not exported by Control.Parallel, this is an oversight on my part, you have to import it from GHC.Conc for now. For 6.8 we'll export pseq from Control.Parallel instead of seq. Incedentally, the fixity of par is also wrong in 6.6: it should be infixr 0, but in fact it has the default fixity of infixl 0. This means if you write an expression like 'x `par` y `seq` z', it isn't doing what you think. Workaround: either use parentheses, or define your own par with the right fixity. Cheers, Simon

4 15

hsman
by Frederik Eaton 07 Nov '06

07 Nov '06

Hello, I have a perl script which I call 'hsman', which indexes Haddock-generated HTML files, and allows users to search for functions and also GHC manual topics. For instance, I can run: $ hsman foldl to open the documentation on 'foldl'. There is also tab-completion in zsh. If people think this would be useful to others, then I can polish it up to be included with 'ghc' distribution. Does that sound like a good idea? Best, Frederik -- http://ofb.net/~frederik/

7 11

Template Haskell quotion for []
by Krasimir Angelov 07 Nov '06

07 Nov '06

Hello, I had this example that was working with earliest versions of GHC but it doesn't work with GHC-6.6. $(deriveReflectable ''[]) Above this isn't a double quote but two single quotes. It may not be clear with some fonts. Is this a bug or just there is a change in the syntax? The error that I get is: src/Database/HarmonyDB/Instances.hs:1:0: Illegal variable name: `[]' When splicing generated code into the program Regards, Krasimir

1 0

make option suggestion
by Frederik Eaton 07 Nov '06

07 Nov '06

Hello, I have a proposal for ghc. I think that it should take a new option, say "--make-command". This will specify a command to be run whenever a source file is read in by ghc. The command will be passed an argument, which is the name of the source file. The idea is that the command can be used to create auto-generated "source" files when ghc needs them. The purpose of this would be the following. Suppose I have a source file, say Source.hs, which is generated from some template, say Source.hs.in. If I edit Source.hs.in, and compile my program with 'ghc --make', then the copy of Source.hs which ghc uses will be out of date. That's because ghc doesn't know about the fact that Source.hs is generated from Source.hs.in. If I use ghc, then I'll have to remember to manually generate a new version of Source.hs every time I modify Source.hs.in. But under the present proposal, I would simply write a Makefile with the rules for generating Source.hs, and then pass --make-command=make to ghc. For instance, my Makefile might say: Source.hs: Source.hs.in $(TAC) < $< > $@ Then every time I run ghc, and Source.hs is out of date, an up-to-date version of Source.hs will be generated automatically - because ghc will call 'make Source.hs' before reading it in. Does this sound like a good idea? Frederik -- http://ofb.net/~frederik/

5 7

Memory leak in FFI callback: GHC 6.6
by SevenThunders 06 Nov '06

06 Nov '06

I'm not sure if this is a bug, but it sure seems that way to me. When using the "wrapper" technique for creating a Haskell callback function it seems that freeHaskellFunPtr is not properly freeing the resource. Here is an example program <leaky.hs> module Main where import Foreign import Foreign.Ptr import Foreign.Storable -- | A convenient type synonym for storable arrays type Darr = Ptr (Double) -- | Function type for mapping doubles to doubles type Dfunc = Double -> Double -- | A convenient type synonym for monad containing storable arrays type IODarr = IO (Darr) foreign import ccall "wrapper" mkDfunc :: Dfunc -> IO (FunPtr Dfunc) foreign import ccall "cleaky.h cfunc" cfunc :: (FunPtr Dfunc) -> IO ( Double ) dadd :: Dfunc dadd x = x + 1.0 getleaky :: Dfunc -> IO () getleaky cf = do pcf <- mkDfunc cf -- pd <- cfunc pcf print pcf freeHaskellFunPtr pcf main = sequence_ [getleaky dadd | q <- [1..500000]] It's compiled with ghc -fglasgow-exts -fffi -prof -auto -I. --make leaky.hs cleaky.o A possible cleaky.c and cleaky.h are #include <math.h> #include <stdio.h> #include "cleaky.h" double state = 1.0 ; double cfunc(DFptr fptr) { // printf("In cfunc, fptr: %p\n", fptr) ; state = (*fptr) (state) ; // printf("state: %g\n", state) ; return(state) ; } typedef double (*DFptr) (double) ; double cfunc(DFptr) ; though they are not used. leaky.exe grows the heap linearly without bound on windows XP 64. The profiler never reports this correctly either. calling leaky +RTS -hc -RTS does not show the increase in the memory usage. -- View this message in context: http://www.nabble.com/Memory-leak-in-FFI-callback%3A-GHC-6.6-tf2565446.html… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

2 3