February 2011 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

MonoLocalBinds and hoopl
by Edward Z. Yang 20 Jun '11

20 Jun '11

Hello all, Here's an experience report for porting hoopl to manage MonoLocalBinds. The Compiler.Hoop.XUtil module has a rather interesting (but probably common) style of code writing, along the lines of this: fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock f m l cat) block where f n = FF3 $ ff n m n = FF3 $ fm n l n = FF3 $ fl n FF3 f `cat` FF3 f' = FF3 $ f' . f f, m, l and cat are polymorphic functions that are only used once in the main expression, and are floated outside to improve readability. However, when MonoLocalBinds is turned on, these all become monomorphic and the definitions fail. In contrast, this (uglier) version typechecks: fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock (FF3 . ff) (FF3 . fm) (FF3 . fl) (\(FF3 f) (FF3 f') -> FF3 $ f' . f)) block One suggestion that I had was that we should generalize local bindings that are only used once, but Marlow pointed out that this would make the typechecker more complex and I probably would agree. As a userspace developer, I have two options: 1. Bite the bullet and put in the polymorphic type signatures (which can be quite hefty) 2. Inline the definitions 3. Move the polymorphic functions into the global namespace (3) and (2) are not so nice because it breaks the nice symmetry between these definitions, which always define f, m, l for the many, many definitions in Hoopl of this style. Cheers, Edward

6 8

Tracing idea
by Edward Z. Yang 13 May '11

13 May '11

I was thinking it might be useful if we had a per-thread circular buffer in memory for which we pushed a pointer to the info table we had just entered. In the event of a crash, you could dump the contents of the buffer to see what code had been recently executed. To reduce overhead, one might only need to record this information when we do a tail call, and not when the path can be reconstructed from the stack. (Obviously, you'd need to compile in debug mode, and you'd probably want to also add an RTS flag). What do people think? Cheers, Edward

3 4

ANNOUNCE: GHC 7.0.2 Release Candidate 2
by Ian Lynagh 17 Mar '11

17 Mar '11

We are pleased to announce the second release candidate for GHC 7.0.2: http://www.haskell.org/ghc/dist/7.0.2-rc2/ This includes the source tarball, the Windows installer, and bindists for 32bit and 64bit Intel OS X, amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. Please test as much as possible; bugs are much cheaper if we find them before the release! Our plan is to make the 7.0.2 release in around a week, and that will be the last release from the 7.0 branch, as we'll then switch to using the git repository for development. The 7.2.1 release will follow shortly. Thanks Ian, on behalf of the GHC team

8 27

GHC build error: cannot satisfy -package ghc-7.1.20110217
by William Knop 15 Mar '11

15 Mar '11

Hi all, I'm building GHC HEAD, and I've encountered the following error a couple times: "/usr/bin/ghc" -M -dep-makefile ghc/stage1/build/.depend.haskell.tmp > -include-pkg-deps -H32m -O -package-conf libraries/bootstrapping.conf > -hide-all-packages -i -ighc/. -ighc/stage1/build -ighc/stage1/build/autogen > -Ighc/stage1/build -Ighc/stage1/build/autogen -optP-include > -optPghc/stage1/build/autogen/cabal_macros.h -package array-0.3.0.2 -package > base-4.3.1.0 -package bytestring-0.9.1.10 -package directory-1.1.0.0 > -package filepath-1.2.0.0 -package ghc-7.1.20110217 -package process-1.0.1.4 > -package unix-2.4.1.0 -Wall -XHaskell98 -XNondecreasingIndentation -XCPP > -XPatternGuards -no-user-package-conf -rtsopts -odir ghc/stage1/build -hidir > ghc/stage1/build -stubdir ghc/stage1/build -hisuf hi -osuf o -hcsuf hc > ghc/./Main.hs <command line>: cannot satisfy -package ghc-7.1.20110217: ghc-7.1.20110217-b77087559342dd20dfcfb258ea8804c4 is unusable due to > missing or recursive dependencies: Cabal-1.11.0-94afda515f19c403e7bc1e64b05e7f80 > bin-package-db-0.0.0.0-e7fefdd6f3601d1ce130006fe020c686 > hoopl-3.8.6.1-9f2c1afa2d4e6e1f5dd2821dfd6b919b > hpc-0.5.0.6-71c33aa47ae2440fd78a2a606987bc82 (use -v for more information) make[1]: *** [ghc/stage1/build/.depend.haskell] Error 1 make: *** [all] Error 2 The last time I saw this, I realized that `make clean` and even `make maintainer-clean` failed to remove the old .hs and .o files in ./libraries. I ran `find ./libraries | grep "\.hi$\|\.o$" | xargs -n 1 rm` which cleaned things up nicely. Then I had to fiddle around with `ghc-pkg` and unfortunately I don't remember exactly what I did, but everything built fine. This time, the error persists and I'm getting nowhere messing with `ghc-pkg` or manual builds of the offending libraries. It's odd that the dependencies are all shown, although ghc-7.1.20110217 is highlighted in blue (not sure what that means): $ ghc-pkg list -v using cache: > /Users/wknop/.ghc/x86_64-darwin-7.1.20110217/package.conf.d/package.cache using cache: > /Library/Frameworks/GHC.framework/Versions/7.1.20110217-x86_64/usr/lib/ghc-7.1.20110217/package.conf.d/package.cache /Library/Frameworks/GHC.framework/Versions/7.1.20110217-x86_64/usr/lib/ghc-7.1.20110217/package.conf.d Cabal-1.11.0 (Cabal-1.11.0-94afda515f19c403e7bc1e64b05e7f80) array-0.3.0.2 (array-0.3.0.2-82b79889a63c9f1c51bec752ba6e74c2) base-4.3.1.0 (base-4.3.1.0-772e705367f0e57fa35bb2732ef27d5f) bin-package-db-0.0.0.0 > (bin-package-db-0.0.0.0-e7fefdd6f3601d1ce130006fe020c686) binary-0.5.0.2 (binary-0.5.0.2-0fc98c736c6f368bb204d82d52e9b985) bytestring-0.9.1.10 > (bytestring-0.9.1.10-9ed25604136f5805a5307d3964bed1a2) containers-0.4.0.0 (containers-0.4.0.0-e65ebc811ae84f909e4426649d5305b6) directory-1.1.0.0 (directory-1.1.0.0-af496658c243f2bddd90748bc896b9cb) extensible-exceptions-0.1.1.2 > (extensible-exceptions-0.1.1.2-d8c5b906654260efd7249f497d17a831) ffi-1.0 (builtin_ffi) filepath-1.2.0.0 (filepath-1.2.0.0-083d27aec2076819a3255aa35e2ce43b) ghc-7.1.20110217 (ghc-7.1.20110217-b77087559342dd20dfcfb258ea8804c4) ghc-prim-0.2.0.0 (ghc-prim-0.2.0.0-dcc46e56b3af1fa9c9fa226ef635850d) haskell2010-1.0.0.0 > (haskell2010-1.0.0.0-5a47cd47ec15d3267342d7569d62be69) haskell98-1.1.0.0 (haskell98-1.1.0.0-ff2f72cc8added329f0e4b03c5cc83e8) hoopl-3.8.6.1 (hoopl-3.8.6.1-9f2c1afa2d4e6e1f5dd2821dfd6b919b) hpc-0.5.0.6 (hpc-0.5.0.6-71c33aa47ae2440fd78a2a606987bc82) integer-gmp-0.2.0.2 > (integer-gmp-0.2.0.2-a1c2a972ace139a643a7e915357c7135) old-locale-1.0.0.2 (old-locale-1.0.0.2-f8974f34bd37bc556cfeca15f8cf9933) old-time-1.0.0.6 (old-time-1.0.0.6-caa2975bbf8e858473e1d88cca412718) pretty-1.0.2.0 (pretty-1.0.2.0-86ef771ce2f9bebde0154187a7714390) process-1.0.1.4 (process-1.0.1.4-8e5c7fd6eb02062956e817290e78052c) random-1.0.0.3 (random-1.0.0.3-ba5d71475c84afcd915bdd0c7896d252) rts-1.0 (builtin_rts) template-haskell-2.5.0.0 > (template-haskell-2.5.0.0-d8450268cce481f1f0f0609421f45d6a) time-1.2.0.3 (time-1.2.0.3-54ba5c61f979a06ebaa014e89cb57800) unix-2.4.1.0 (unix-2.4.1.0-ed4a568ba9e55a6699f0a5637de1eb70) /Users/wknop/.ghc/x86_64-darwin-7.1.20110217/package.conf.d HUnit-1.2.2.3 (HUnit-1.2.2.3-cfbd4873c8348462ffebec9e0e2612ff) QuickCheck-2.4.0.1 (QuickCheck-2.4.0.1-203424cf15ac4e156e45863bdb6c5c3c) ansi-terminal-0.5.5 > (ansi-terminal-0.5.5-572a1d0154fb2632bb4e9431adf0cdb1) ansi-wl-pprint-0.6.3 > (ansi-wl-pprint-0.6.3-875ef2078f6bfbf85f537bf474d4db67) hostname-1.0 (hostname-1.0-fd008e4cbc7e53cd089e95782cd47a3a) mtl-2.0.1.0 (mtl-2.0.1.0-86fd290a44e249d2b21a3e6adc3985a4) regex-base-0.93.2 (regex-base-0.93.2-f611e499723a1c17ae67e04fe4ce3d1e) regex-posix-0.94.4 (regex-posix-0.94.4-9e243c82c4410fcdd8b9c4a9f579cd23) test-framework-0.3.3 > (test-framework-0.3.3-2e089ba99de1028033d51a65ef26cced) test-framework-hunit-0.2.6 > (test-framework-hunit-0.2.6-cd25c078816dfb54dc08cf64d24bcea2) test-framework-quickcheck2-0.2.9 > (test-framework-quickcheck2-0.2.9-0063f8833c46c25ff4d6bb13461990f8) transformers-0.2.2.0 > (transformers-0.2.2.0-5facb5b7c533677975df4a82c67e8639) xml-1.3.7 (xml-1.3.7-eb24b369ce1c655abc9947262d56223e) The other notable thing is that the versions of the installed packages matches the packages I am building with GHC. I initially thought that it would be a good thing, however now I'm thinking that it's leading to some kind of conflict between the build system and the bootstrap system. In the past I've noticed that cabal does not deal well with different versions of GHC, particularly that it doesn't keep track which version of GHC is used to build and register a package (and the .cabal user directory doesn't have separate subdirectories for different cabal versions). This is quite annoying, since it means one can't really have test installs of GHC without fiddling around with prefixes or sandbox construction. Anyway, I wouldn't be surprised if conflicts from that sort of thing could cause the issue I'm having. So I suppose the question now is, what is the actual cause and should it be fixed in GHC's build system or in cabal's source? Thanks, William

3 7

trac ticket spam
by Claus Reinke 15 Mar '11

15 Mar '11

Is there any way to have a "moderate first comment by new submitter" policy for trac, to avoid the kind of ticket spam we have at the moment? They seem to have started commenting on existing tickets now (#4510), which could turn into a real mess really quickly, if the currently known spam accounts aren't blocked soon, btw. Claus

6 10

Faster Array#/MutableArray# copies
by Johan Tibell 02 Mar '11

02 Mar '11

Hi, Daniel Peebles has done a great job adding new primops for copying arrays (both Array# and MutableArray#). This gave me a nice speedup for my hash-array mapped trie (HAMT) data structure, which is now about as fast as Data.Map for inserts but about 5.5x faster for lookups. (It should also have a lower per key/value overhead.) However, for the HAMT is more than twice as slow for inserts compared to IntMap and copying arrays is still the bottleneck. C compilers, like gcc, go to great lengths making memcpy fast and I was thinking that we might be able to steal a trick or two from them. I'd like some feedback on these ideas: * Could we try to make the array primops inline? If so, would that mean that if e.g. the number of elements to copy is known at the (Haskell) call site it would also be known in C-- and we could get the benefits of knowing that? * Could we use built-in compiler rules to catch array copies of known length and replace them with e.g. unrolled loops? My particular use case involves copying small arrays (size: 1-32). Ideally this should be as fast as copying a tuple of the corresponding size but I'm pretty sure we're far off that goal. * Can we use SSE instructions? * Can we get the C memcpy code inlined into the C-- source (crazy, I know). If so we could perhaps benefit directly from optimizations in libc. Johan

7 12

SMP parallelism gains inferior than expected
by José Pedro Magalhães 01 Mar '11

01 Mar '11

Hi, I have a program that computes a matrix of Floats of m rows by n columns. Computing each Float is relatively expensive. Each line is completely independent of the others, so I thought I'd try some simple SMP parallelism on this code: myFun :: FilePath -> IO () myFun fp = do fs <- readDataDir fp let process f = readFile' f >>= parse printLine = putStrLn . foldr (\a b -> show a ++ "\t" ++ b) "" runDiff l = [ [ diff x y | y <- l ] | (x,i) <- zip l (map getId fs), myFilter i ] ps <- mapM process fs sequence_ [ printLine x | x <- runDiff ps *`using` parList rdeepseq* ] So, I'm using parList to evaluate the rows in parallel, and fully evaluating each row. Here are the timings on a Dual Quad Core AMD 2378 @2.4 GHz, ghc-6.12.3, parallel-2.2.0.1: -N time (ms) none 1m50 2 1m33 3 1m35 4 1m22 5 1m11 6 1m06 7 1m45 The increase at 7 is justified by the fact that there were two other processes running. I don't know how to justify the small increase at N3, though, but that doesn't matter too much. The problem is that I am not getting the gains I expected (halving at N2, a third at N3, etc.). Is this the best one can achieve with this implicit parallelism, or am I doing something wrong? In particular, is the way I'm printing the results at the end destroying potential parallel gains? Any insights on this are appreciated. Thanks, Pedro

2 2

ghc-pkg regression (or deliberate change)?
by Tyler Pirtle 01 Mar '11

01 Mar '11

Hi there, I'm using a system with an older version of GHC (6.8.3), and invoking ghc-pkg against a non-existing file in -f: $ haskell/ghc/v683/k8/lib/ghc-6.8.3/ghc-pkg.bin --global-conf haskell/ghc/v683/k8/lib/ghc-6.8.3/package.conf -f /tmp/nonexistent.Foo.package.conf register /tmp/Foo.package_spec ghc-pkg happily creates the file referenced with -f and fills it with these contents: [InstalledPackageInfo {package = PackageIdentifier {pkgName = "hsS-SFoo", pkgVersion = Version {versionBranch = [1,0], versionTags = []}}, license = AllRightsReserved, copyright = "", maintainer = "", author = "", stability = "", homepage = "", pkgUrl = "", description = "", category = "", exposed = False, exposedModules = [], hiddenModules = [], importDirs = [], libraryDirs = [], hsLibraries = [], extraLibraries = [], extraGHCiLibraries = [], includeDirs = [], includes = [], depends = [], hugsOptions = [], ccOptions = [], ldOptions = [], frameworkDirs = [], frameworks = [], haddockInterfaces = [], haddockHTMLs = []} ] GHC 7.0.1 it appears does not do the same thing: $ haskell/ghc/v701/k8/lib/ghc-7.0.1/ghc-pkg --global-conf haskell/ghc/v701/k8/lib/ghc-7.0.1/package.conf.d -f /tmp/nonexistent.Foo.package_conf --force register /tmp/Foo.package_spec ghc-pkg: .../bin/hs/Foo.package_conf: openFile: does not exist (No such file or directory) (paths have been mangled by hand). ghc-pkg in 6.8.3 does what it does even without using --force. What am i missing in 7.0.1? Is this a bug or is this intentional? Thanks, Tyler

2 1

ANNOUNCE: GHC 7.0.2 Release Candidate 1
by Ian Lynagh 27 Feb '11

27 Feb '11

We are pleased to announce the first release candidate for GHC 7.0.2: http://www.haskell.org/ghc/dist/7.0.2-rc1/ This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. 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

10 17