- Glasgow-haskell-users

Prefix form of unboxed tuple
by Neil Mitchell 06 Jul '07

06 Jul '07

Hi, The following works fine: ghci -fglasgow-exts Prelude> case (# 1 , 2 #) of (# a , b #) -> error $ show (a,b) *** Exception: (1,2) You might expect there to be a prefix form of the unboxed tuple: Prelude> case (#,#) 1 2 of (# a , b #) -> error $ show (a,b) <interactive>:1:7: parse error on input `,' But there isn't. I've added special code into the Yhc code generator to deal with this particular constructor, so it no longer effects me. Thanks Neil

5 6

problem compiling an older Haskell program with GHC 6.6.1
by Scott Stoller 06 Jul '07

06 Jul '07

hi, I am trying to compile paradox 1.0, an older (GHC 5) Haskell program, with GHC 6.6.1 (the Solaris 10 / x86 binary distribution). in case anyone else wants to try it, I put the paradox source code at http://www.cs.sunysb.edu/~stoller/out/paradox-1.0-casc.tar.gz in the Makefile, I deleted "-package lang" from HFLAGS, and added "-v" to it. then I typed "make". I got the following error message: Glasgow Haskell Compiler, Version 6.6.1, for Haskell 98, compiled by GHC version 6.6.1 Using package config file: /usr/local/lib/ghc-6.6.1/package.conf wired-in package base mapped to base-2.1.1 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0 wired-in package template-haskell mapped to template-haskell-2.1 Hsc static flags: -static Created temporary directory: /tmp/ghc13306_0 *** Chasing dependencies: Set.hs:26:7: Could not find module `Data.FiniteMap': locations searched: Data/FiniteMap.hs Data/FiniteMap.lhs *** Deleting temp files: Deleting: /tmp/ghc13306_0/ghc13306_0.dep *** Deleting temp dirs: Deleting: /tmp/ghc13306_0 make: *** [depend.mak] Error 1 is this a backwards-compatibility issue between GHC 6.6.1 and older versions of GHC? is there a simple workaround? I can't easily use an older version of GHC, because I don't see binary distributions of older versions of GHC for Solaris x86. any advice would be greatly appreciated. best regards, scott

3 2

RTS/Garbage Collector idea
by Isaac Dupree 06 Jul '07

06 Jul '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It's often bothered me that there is unneeded duplication in the heap, if you do something the compiler doesn't manage to optimize like f [a,b,c,d] = Foo bar [a,b,c,d] or (reverse . reverse) or using () or Int(eger) or ... or Bool boxes in multiple places in your program that have the same value. A referentially transparent difference in your program could be the difference between constant memory usage and a memory leak (I think -- although this proposal/idea will not "tie the knot" for you or deal well with cyclic data structures at all, in fact). I was thinking, since we have a copying garbage collector that reassigns all pointers anyway, could we detect the "identical" heap objects and for each set of identical ones, have all thunks that pointed to any of them, now point to the single one that is created in the target space? This might not have much effect. (and seems likely to be slow and possibly have a complex interaction with parallel and/or incremental GC...) Maybe it should not be done on _every_ garbage collection. First to implement/try might be just detecting those duplicates so we have some idea how much effect such an "optimization" would even have. (any idea how easy/possible that is (or just what the answer is;)?) Examples: evaluated (543::Int) somewhere ends up pointing to the same (543# :: Int#) in the heap as another (543::Int) somewhere does. 8:8:2:3:[] 9:9:2:3:[] The []s become shared, then the "3:[]"s, then the "2:3:[]"s, ending 8:8:x 9:9:x where x is 2:3:[] 8:8:2:3:(*) 9:9:2:3:(*) where (*) is the *same* object, maybe an unevaluated thunk, maybe some list. After (*)'s creation, two different parts of code decided to construct their own lists with that as their tail. Eventually becomes: 8:8:x 9:9:x where x is 2:3:(*) Two thunks that merely have the same code shouldn't be combined because it could be the [1..] [1..] sharing memory-leak to the extreme! It would seem safe to combine thunks that only produce something small like an Int, but they can actually produce a complex Exception - so, no combining of thunks. (also... must be careful in this area of breaking the IO monad-sequencing(maybe?), but I think it's quite safe as long as only already-evaluated heap objects are combined) I wonder how this interacts with polymorphic (list-nil of different types), or with merely structurally equivalent, data (if they're identical, merging shouldn't ever be a problem! at least as long as no-one relies on something like "if (unsafe pointer equality) then (same static type)"...) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdmJaHgcxvIWYTTURAjAhAJ9WHwzxuJPuqouol05K7+QHkT3IigCglOpw VtHCSxcy8E+w7OtCafU8pFM= =BqAi -----END PGP SIGNATURE-----

6 6

Need help understanding the Coverage Condition
by Philip K.F. Hölzenspies 04 Jul '07

04 Jul '07

L.S., I have difficulty understanding the Coverage Condition. Hopefully, someone has the time and is willing to explain this to me. Obviously, I went ahead and hacked together something horribly entangled, but I found a small example that already shows the behaviour I do not understand. Type-level addition of Church numerals: {- begin -} {-# OPTIONS -fglasgow-exts #-} data Z -- Zero data S x -- Successor of x class Add a b c | a b -> c instance Add Z q q instance Add p q r => (S p) q (S r) {- end -} The error GHCi produces is: Illegal instance declaration for `Add (S x) y (S z)' (the Coverage Condition fails for one of the functional dependencies; Use -fallow-undecidable-instances to permit this) In the instance declaration for `Add (S x) y (S z)' Failed, modules loaded: none. I checked the user guide (7.4.4.1) for criteria for functional dependencies and checked that I do not violate the assertions. I don't violate assertions 1a and 1b, but assertion 2 (the coverage condition) I have trouble reading: The coverage condition. For each functional dependency, tvc_left -> tvs_right, of the class, every type variable in S(tvs_right) must appear in S(tvs_left), where S is the substitution mapping each type variable in the class declaration to the corresponding type in the instance declaration. In my mind, in this case: tvs_left = {a,b} tvs_right = {c} S(tvs_left) = {p,q} S(tvs_right) = {r} What "occur in" means (mappings of type variables occurring in mappings of other type variables), I really don't quite understand. The example in the manual under 7.4.4.2, viz: instance Mul a b c => Mul a [b] [c] where x .*. v = map (x.*.) v seams related, but unfortunately is not elaborated upon beyond "[it] does not obey the coverage condition" The suggested flag to "allow undecidable instances" is throwing me off, since it seems very unambiguously decidable to me. Regards, Philip

3 3

Vote for GHC 6.8 bugs!
by Simon Peyton-Jones 03 Jul '07

03 Jul '07

Friends, We are gearing up towards at GHC 6.8 release. You can see details of what will be in it in the GHC status report for April http://hackage.haskell.org/trac/ghc/wiki/Status/April07. One symptom of the sharply-increased use of GHC is the sharply-increased number of bug reports and feature requests. We have no fewer than 200 milestoned for 6.8! You can see a summary here: http://hackage.haskell.org/trac/ghc/roadmap In reality we're unlikely to fix all 200, at least not without a lot of help from our friends. Inevitably, we have to prioritise. One way we do that is by using our (unreliable) perception of which bugs you (GHC's users) care about. This message is to invite you to improve the accuracy of this perception, by voting for the bugs you care about. We have just instituted a cheap-and-cheerful mechanism for voting. Each bug has a 'cc' field. To vote, just add your email address to the cc field! Better still, add a note to say why you care, and/or add a test case. We'll use the number of cc's (and an informal impression of any notes you've added) to guide our priorities. Adding yourself to the cc list means you'll get mail whenever anyone modifies the Trac report, which keeps you informed of what's going on. (You have to log in to edit Trac reports. Currently, new accounts are disabled for boring spammy reasons. That will be fixed when we upgrade Trac, but meanwhile, log in as guest, password guest.) It's not a perfect system, but we think it'll give useful extra guidance. So please go ahead and vote. But better still, help us fix bugs! GHC is open-source software, and it has a very large "surface area" (many platforms, many libraries, many features, documentation, tools, etc etc). Lots of people help make GHC good -- please join in (see the "Joining in" list in the GHC Wiki sidebar http://hackage.haskell.org/trac/ghc/wiki/) thanks Simon

3 2

How to compile .hc files with gcc?
by Srđan Stipić 03 Jul '07

03 Jul '07

I wanted to compile simple Haskell program (simple.hs) to .c and after that to target platform (x86). I did the following things: ghc -C simple.hs mv simple.hc simple.c gcc -c simple.c -I/usr/lib/ghc-6.6/include/ And I got the following error message: In file included from /usr/lib/ghc-6.6/include/Stg.h:148, from treci.c:3: /usr/lib/ghc-6.6/include/Regs.h:220: warning: call-clobbered register used for global register variable /usr/lib/ghc-6.6/include/Regs.h:226: warning: call-clobbered register used for global register variable /tmp/ccBtIPsT.s: Assembler messages: /tmp/ccBtIPsT.s:31: Error: junk at end of line, first unrecognized character is `-' /tmp/ccBtIPsT.s:63: Error: junk at end of line, first unrecognized character is `-' How to compile .hc files with gcc? Tnx, Srdjan

2 2

-keep-hc-files or -keep-hc-file?
by Christian Maeder 02 Jul '07

02 Jul '07

I'm currently confused if it must be plural or singular (or any) http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilatio… shows plural options whereas http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html… shows them in singular (except -keep-tmp-files) Cheers Christian

3 3

readArray is faster than unsafeRead
by Scott Dillard 01 Jul '07

01 Jul '07

Hello, I'm writing some matrix multiplication and inversion functions for small matrices (3x3 and 4x4 mostly, for 3d graphics, modeling, simulation, etc.) I noticed that the matrix multiplication was a bottleneck so I set out to optimize and found that using unsafeRead instead of (!) (or readArray in stateful code) helped a lot. So then I went to optimize my gaussian elimination function and found just the opposite. unsafeRead is slower than readArray. This struck me as very odd considering that readArray calls unsafeRead. If there is a "good" reason why the compiler optimized readArray better than unsafeRead, I'd like to know what it is so that I can make all my array code safe as well as fast. (By "good" reason I mean something deterministic and repeatable, not just luck.) On the otherhand, if this is a fluke, I'm inclined to think that it's not the safe code which is freakishly fast, but the unsafe code which is needlessly slow. That is, something about my program is hindering optimization of the unsafe code. What is it? Attached is the profiling results and a test program with a handful of matrix multiplication and gaussian elimination functions to illustrate what I've seen. This happens both on amd64 and intel core architectures. Thanks for any insight, Scott

5 6

6.6.1 on long lists
by Serge D. Mechveliani 30 Jun '07

30 Jun '07

Dear GHC developers, I tried to test the ghc-6.6.1 performance on long lists. And there is something a bit suspicious about the test. Consider the program ----------------------------------------- main = putStr (shows res "\n") where n = k*10^6 :: Int k = 2 -- put k = 2,4,6, ... res = head $ rev [1 .. n] rev xs = r [] xs where r xs [] = xs r xs (y: ys) = r (y: xs) ys ----------------------------------------- 512 Mb RAM machine, Pentium 4, 1.6 GHz, Debian Linux. `Making': ghc -O --make Main Running time Main +RTS -M400m -RTS ---- ghc-6.6.1 -------------------| k time [sec] minimal needed ghc-5.02.3 for 400Mb heap (-M..) [Mb] 2 1.3 41 2 sec 41 Mb 4 3.0 6 7.8 8 8.8 164 8 ------------------ 10 23.7 12 24.7 244 14 25.1 13 ----------------------------------------------------------------- Should the cost of this program be linear in k ? For example: 8/4 = 2, time(8)/time(4) = 8.8/3.0 =~= 2.9 Should this ratio be near 2.0 ? Further, at k = 10, the time jumps. This is, probably, due to that a list of 10*10^6 ints takes about 8*10*10^6 bytes =~= 80 Mb (please, is this so ?), the program may need a copy of this list ... and this total may be close to -M400M (?), and thus garbage collection happens (once). After k = 10, it looks again like linear. My impression is that at the segment k <- [2, 8] the cost is about k*(log k). Thank you in advance for your comments. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

ghc api, some simple questions
by Claus Reinke 29 Jun '07

29 Jun '07

- {-# OPTIONS_GHC -package ghc #-} would be useful, doesn't give a warning, but doesn't work, either. -package works in ghci, but not in source pragmas, why? - hostSession hardcoding topDir doesn't seem to be a good idea. shouldn't GHC export means to get at the "hosting" ghc session (the one compiling the current code), so that one could ask for topDir there? currently, i'm calling "ghc --print-libdir" externally .. if nothing else, perhaps something like the 'ghcDir' hack from the example below could be in GHC? - ppr/printForUser should GHC reexport Outputable? also, ppr doesn't seem to handle infix op definitions correctly, printing the left-hand side in prefix form, but without parentheses? [ghc 6.6.1] claus ----------------------------------------------------- {-# OPTIONS_GHC -package ghc #-} module API where import DynFlags import GHC import System.Process import System.IO import Outputable mode = Interactive -- shouldn't something like this be in System.Process? writer >| cmd = runInteractiveCommand cmd >>= \(i,o,e,p)->writer i cmd |> reader = runInteractiveCommand cmd >>= \(i,o,e,p)->reader o -- shouldn't GHC export a hostSession, -- so that we could ask for things like topDir there? ghcDir = "ghc --print-libdir" |> (fmap dropLineEnds . hGetContents) where dropLineEnds = filter (not . (`elem` "\r\n")) main = defaultErrorHandler defaultDynFlags $ do s <- newSession mode . Just =<< ghcDir flags <- getSessionDynFlags s (flags, _) <- parseDynamicFlags flags ["-package ghc"] GHC.defaultCleanupHandler flags $ do setSessionDynFlags s flags{ hscTarget=HscInterpreted } addTarget s =<< guessTarget "API.hs" Nothing load s LoadAllTargets prelude <- findModule s (mkModuleName "Prelude") Nothing usermod <- findModule s (mkModuleName "API") Nothing setContext s [usermod] [prelude] Just cm <- checkModule s (mkModuleName "API") unqual <- getPrintUnqual s printForUser stdout unqual $ ppr $ parsedSource cm

1 0