- Glasgow-haskell-users

fromJust Nothing problem
by Serge D. Mechveliani 15 Nov '06

15 Nov '06

Thanks to people who discussed the question of "who said `fromJust Nothing'" and -xc option. My last impression is that instead of using -xc it is better to write programs in a debug-friendly style. For example, let g x must return (Just _), but the programmer is not 100% sure that g x is free of bugs. Then, instead of f x = h $ fromJust $ g x one needs too write f x = case g x of Just y -> h y _ -> error $ concat ["Foo.f ", shows x "\n:\nImpossible happened:\n", "g ", shows x " = Nothing.\n" ] ----------------- Serge Mechveliani mechvel(a)botik.ru

5 6

locating fromJust Nothing
by Serge D. Mechveliani 14 Nov '06

14 Nov '06

More about finding the source of fromJust Nothing. For g n = fromJust $ f n, ghc-6.6 often looses the reference to f in its run-time error report -- when f returns Nothing. And this is difficult to locate the source. But one could write g n = let Just m = f n in m, for which GHC reports Main: M1.hs:9:11-22: Irrefutable pattern failed for pattern Data.Maybe.Just m -- it points to the source line! ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Cabals' Paths_pkg and GHCi
by Vyacheslav Akhmechet 14 Nov '06

14 Nov '06

Hi, I took advantage of Cabal's data-files feature to allow me to portably store and access data files. Cabal generated a Paths_pkg module that I imported. From Cabal's point of view everything works: I can configure, build, install, and run. However, I can no longer use GHCi with the file that imports Paths_pkg - GHCi simply can't find the module. Is there a good way to fix this issue? Thanks, - Slava.

4 3

-xc
by Serge D. Mechveliani 14 Nov '06

14 Nov '06

Simon P. Jones wrote today about the -xc option to help with finding who called fromJust Noting. Now, I see in the GHC Guide: ------------------------------------------------------------------ -xs (Only available when the program is compiled for profiling.) When an exception is raised in the program, this option causes the current cost-centre-stack to be dumped to stderr. This can be particularly useful for debugging: if your program is complaining about a head [] error and you haven't got a clue which bit of code is causing it, compiling with -prof -auto-all and running with +RTS -xc -RTS will tell you exactly the call stack at the point the error was raised. The output contains one line for each exception raised in the program (the program might raise and catch several exceptions during its execution), where each line is of the form: < cc1, ..., ccn > ... --------------------------------------------------------------------- So, I `made' the project under -prof -auto-all and run ./Nat1 +RTS -xc -RTS. It prints ... (3, Ind n, (formula1 [(1, IndMember, <Data.Maybe.CAF>Nat1: Maybe.fromJust: Nothing This does not help to see who called for fromJust in this case. Maybe this is in Nat.prof ? And it is empty. Adding -p does fill Nat.prof with a lot of statistics, but I guess, this statistics cannot help with the fromJust question. Can people, please, comment some more on this -xc usage? Thank you in advance for explanation, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

GHC submission guidelines
by Simon Marlow 14 Nov '06

14 Nov '06

Dear GHC folks, We (well, mostly SimonPJ) have written down a set of guidelines for contributing to GHC on the wiki: http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions If you're interested in contributing, please take a look. The requirements are mostly common sense and not too onerous, but keeping to them will help make life easier for the GHC maintainers. Thanks! By the way, if you haven't browsed the GHC developer's wiki recently, it's well worth a look. The Building Guide is now fully transferred (thanks to Alexey Rodriguez Yakushev for converting the remaining sections), and the Commentary is gradually expanding. Cheers, Simon

1 0

find module of `fromJust Nothing'
by Serge D. Mechveliani 14 Nov '06

14 Nov '06

Who can advise, please, about an error message Nat1: Maybe.fromJust: Nothing ? Probably, this is a bug in my program, and first, I need to locate it. The head test module is Nat1.hs. The output is -------------------------------------------------------------------- ... ... --(ProofSearchState ---------------------------------- tree = (formula1 Any [(1, NegCp (spent cost 1283), (formula1 Any [])) (2, ArC fromList [(n,n_c)], (formula6 Any [(1, NegCp (spent cost 683), (formula6 Any []))])) (3, Ind n, (formula1 [(1, IndMember, Nat1: Maybe.fromJust: Nothing ----------------------------------------------------------------------- -- and break. By the last line GHC says, probably, that executing the module Nat1 caused the call of `fromJust Nothing'. And Nat1.hs does not contain any call of fromJust, neither even the substring of "fromJust". Nat1 imports many other modules. Why GHC does not mention some other module from which this `fromJust Nothing' has directly appeared? Thank you in advance for your explanations, ----------------- Serge Mechveliani mechvel(a)botik.ru

4 4

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