November 2006 - Glasgow-haskell-users

higher rank polymorphism
by Jan Christiansen 17 Nov '06

17 Nov '06

Hi, I want to use a rank 2 data type and end up in typ problems that I don't understand. I would really appreciate any hints to the presented cases or pointers to interesting papers that address the background of these problems. I define the following datatype and a simple function that checks whether the list is empty. data Test = Test (forall a . [a -> a]) null1 :: Test -> Bool null1 (Test []) = True null1 (Test _) = False null2 :: Test -> Bool null2 (Test l) = null l null3 :: Test -> Bool null3 (Test l) = case l of [] -> True _ -> False For null1 ghc reports the following typeerror: Couldn't match expected type `forall a. [a -> a]' against inferred type `[a]' In the pattern: [] In the pattern: Test [] In the definition of `null1': null1 (Test []) = True while null2 and null3 don't cause errors. I don't understand why there is a difference between these definitions of null. cp1 :: Test -> Test cp1 (Test l) = case l of [] -> Test [] (x:xs) -> Test (x:xs) cp2 :: Test -> Test cp2 (Test l) = if null l then Test [] else Test (head l:tail l) For cp1 ghc reports the following typeerror: Inferred type is less polymorphic than expected Quantified type variable `a' is mentioned in the environment: xs :: [a -> a] (bound at UpDownTree.hs:36:10) x :: a -> a (bound at UpDownTree.hs:36:8) In the first argument of `Test', namely `(x : xs)' In the expression: Test (x : xs) In a case alternative: (x : xs) -> Test (x : xs) while for cp2 ghc doesn't report an error. I guess there is a similar reason for this error as for the error for null1. I now want to restrict the polymorphic functions in the data type to types for which there is an instance of the type class Eq. data TestEq = TestEq (forall a . Eq a => [a -> a]) null4 :: TestEq -> Bool null4 (TestEq l) = null l For null4 ghc reports the following typeerror: Ambiguous type variable `a' in the constraint: `Eq a' arising from use of `l' at UpDownClass.hs:37:24 Probable fix: add a type signature that fixes these type variable (s) I obviously cannot add a constraint that constraints a type variable that doesn't occur in the type of null4. I will be very pleased for any hints. Regards, Jan

2 2

ghc-testsuite-6.6 on Macs
by Christian Maeder 16 Nov '06

16 Nov '06

Did someone run the test-suite of the binary distributions? http://www.haskell.org/ghc/dist/6.6/ghc-6.6-ppc-apple-darwin.tar.gz http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-apple-darwin.tar.bz2 I've build a (ppc-) mac-distribution from sources and my results are shown below. I had the following 3 unexpected failures under linux, too (by using "make TEST_HC=<installed ghc>" and the <installed ghc> was from http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-unknown-linux.tar.bz2) cg058(ghci) ghcpkg01(normal) ghcpkg03(normal) I thought the failure signals002(ghci) was related to http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/10947 In fact, I needed to kill the ghc-process to continue the tests. The test files cc004.hs and ffi012.hs failed with several messages of the form: calling convention not supported on this architecture: stdcall When checking declaration: foreign import stdcall safe "wrapper" wrap_f :: F -> IO (FunPtr F) However, they did not make it into the summary Cheers Christian OVERALL SUMMARY for test run started at Mon Oct 23 14:54:15 CEST 2006 1455 total tests, which gave rise to 6441 test cases, of which 0 caused framework failures 1126 were skipped 5242 expected passes 55 expected failures 3 unexpected passes 15 unexpected failures Unexpected passes: barton-mangler-bug(optasm) cholewo-eval(optasm,profasm) Unexpected failures: barton-mangler-bug(opt) cabal02(normal) cg058(ghci) conc019(opt,profasm) conc024(opt) ffi009(ghci) forkprocess01(ghci) galois_raytrace(opt,prof) ghcpkg01(normal) ghcpkg03(normal) joao-circular(prof,profasm) signals002(ghci)

4 7

Debugging partial functions by the rules
by dons＠cse.unsw.edu.au 15 Nov '06

15 Nov '06

So all this talk of locating head [] and fromJust failures got me thinking: Couldn't we just use rewrite rules to rewrite *transparently* all uses of fromJust to safeFromJust, tagging the call site with a location? To work this requires a few things to go right: * a rewrite rule * assertions * and rewrite rules firing before assertions are expanded Let's try this. Consider the program: 1 import qualified Data.Map as M 2 import Data.Maybe 3 4 main = print f 5 6 f = let m = M.fromList 7 [(1,"1") 8 ,(2,"2") 9 ,(3,"3")] 10 s = M.lookup 4 m 11 in fromJust s When we run it we get the not so useful error: $ ./A A: Maybe.fromJust: Nothing Ok, so we have a few tricks for locating this, using LocH (http://www.cse.unsw.edu.au/~dons/loch.html) we can catch an assertion failure, but we have to insert the assertion by hand: 1 import Debug.Trace.Location 2 import qualified Data.Map as M 3 import Data.Maybe 4 5 main = do print f 6 7 f = let m = M.fromList 8 [(1,"1") 9 ,(2,"2") 10 ,(3,"3")] 11 s = M.lookup 4 m 12 in safeFromJust assert s 13 14 safeFromJust a = check a . fromJust Which correctly identifies the call site: $ ./A A: A.hs:12:20-25: Maybe.fromJust: Nothing Now, this approach is a little fragile. 'assert' is only respected by GHC if -O is *not* on, so if we happened to try this trick with -O, we'd get: $ ./A A: Debug.Trace.Location.failure So lesson one: you have to do the bug hunting with -Onot. Currently there's -fignore-asserts for turning off assertions, but no flag for turning them on with -O, Simon, could this be fixed? Could we get a -frespect-asserts that works even with -O ? Ok, assuming this assert trick is used, can we get the compiler to insert the asserts for us? If so, this would be a great advantage, you'd just be able to switch on a flag, or import a debugging module, and your fromJusts would be transparently rewritten. With rewrite rules we do just this! So, to our initial unsafe use of fromJust, we add a rewrite rule: -- -- rewrite fromJust to a located version, and hope that GHC expands -- 'assert' after the rule fires.. -- {-# RULES "located fromJust" fromJust = check assert . myFromJust #-} This just tells the compiler to replace every occurence of fromJust with a assertion-throwing fromJust, should it fail. We have to use myFromJust here, to avoid rule recursion. -- -- Inlined to avoid recursion in the rule: -- myFromJust :: Maybe a -> a myFromJust Nothing = error "Maybe.fromJust: Nothing" -- yuck myFromJust (Just x) = x Ok, so can we get ghc to rewrite fromJust to the safe fromJust magicaly? $ ghc --make -Onot A.hs -fglasgow-exts -ddump-simpl-stats [1 of 1] Compiling Main ( A.hs, A.o ) 1 RuleFired 1 located fromJust Linking A ... Yes, the rule fired! GHC *did* rewrite our fromJust to a more useful fromJust. Running it: $ ./A A: A.hs:19:36-41: Maybe.fromJust: Nothing Looks good! But that is deceiving: the assert was expanded before the rule fired, and refers to the rewrite rule source line (line 19), not the fromJust call site (line 12). Now if we could just have the 'assert' token inserted into the AST before it was expanded, we'd be home and dry. Could this be done with TH? Or could we arrange for asserts in rewrite rules not to be expanded till later? Note that this is still a useful technique, we can rewrite head/fromJust/... to some other possibly more useful message. And if we can constrain the rule to fire in only particular modules, we may be able to narrow down the bug, just by turning on a rule. For example, adding: {-# RULES "located fromJust" fromJust = safeFromJust #-} safeFromJust s = case s of Nothing -> "safeFromJust: failed with Nothing. Ouch" Just x -> x will produce: $ ./A "safeFromJust: failed with Nothing. Ouch" So rewrite rules can be used to transparently alter uses of partial functions like head and fromJust. So, further work: * have 'assert' respected when -O is on * think up a technique for splicing in 'assert' via rewrite rules (or TH ...) such that the src locations are expanded after the rewrite, and correctly reflect the location of the splice point. Any ideas? -- Don

3 4

Re: The wiki [was : fromJust something something]
by Serge D. Mechveliani 15 Nov '06

15 Nov '06

I have put there my message. Thank you. But, generally, I do not understand this `wiki' idea (if this is of wiki). 1. People (like myself) will pollute the Debugging Page, or such, with badly edited and erroneous `draft' ideas, and then, who would like to read this page? 2. I edited this Page by adding my message. And what if some user removes all messages, editing the Page to empty? ----------------- Serge Mechveliani mechvel(a)botik.ru On Wed, Nov 15, 2006 at 10:27:59AM +0000, Simon Peyton-Jones wrote: > Way better thank you. Serge -- just follow the links for instructions! > > [..] > | > | We should be able to add this to the 'help' button, > | > | http://www.haskell.org/haskellwiki/Help:Contents > | > ... > | > | Now this is strange. The 'Help' link should be on every page, along with > | > | the 'Login' button?

3 2

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 13 Nov '06

13 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