January 2008 - 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

ghci and ghc -threaded broken with pipes & forking
by John Goerzen 29 Dec '08

29 Dec '08

Hi, I've been hitting my head against a wall for the past couple of days trying to figure out why my shell-like pipeline code kept hanging. I found fd leakage (file descriptors not being closed), which disrupts EOF detection and can lead to deadlocks. I just couldn't find the problem. I finally tried compiling my test with ghc instead of running it in ghci. And poof, it worked fine the first time. I tried asking on #haskell, and got the suggestion that ghci uses -threaded. I tried compiling my test program with ghc -threaded, and again, same deadlock. My program never calls forkIO or forkOS or any other threading code. You can see my test case with: darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh ghc -fglasgow-exts --make -o test2 test2.hs That'll run fine. If you add -threaded, it will hang. Ideas? Thanks, -- John

13 44

Arrow without `>>>'
by Valery V. Vorotyntsev 03 Sep '08

03 Sep '08

Hi, friends, I've built GHC from darcs, and... Could anybody tell me, what's the purpose of Arrow[1] not having `>>>' method? 1. http://darcs.haskell.org/packages/base/Control/Arrow.hs $ ghci GHCi, version 6.9.20080104: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m + Control.Arrow Prelude Control.Arrow> :i Arrow class (Control.Category.Category a) => Arrow a where arr :: (b -> c) -> a b c pure :: (b -> c) -> a b c first :: a b c -> a (b, d) (c, d) second :: a b c -> a (d, b) (d, c) (***) :: a b c -> a b' c' -> a (b, b') (c, c') (&&&) :: a b c -> a b c' -> a b (c, c') -- Defined in Control.Arrow instance Arrow (->) -- Defined in Control.Arrow instance (Monad m) => Arrow (Kleisli m) -- Defined in Control.Arrow Prelude Control.Arrow> Leaving GHCi. I can't build[2] arrows-0.3 package without `>>>' in Arrow. 2. vvv@fun:~/src/arrows$ darcs w { hunk ./Control/Arrow/Operations.hs 36 +import Control.Category ((>>>)) hunk ./Control/Arrow/Transformer/CoState.hs 23 +import Control.Category ((>>>)) } vvv@fun:~/src/arrows$ runhaskell Setup build Preprocessing library arrows-0.3... Building arrows-0.3... [ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o ) Control/Arrow/Transformer/CoState.hs:29:7: `>>>' is not a (visible) method of class `Arrow' The question arises "should I?", but this is one of lambdabot's[3] depencies. 3. http://code.haskell.org/lambdabot/ Thanks a lot! -- vvv

3 3

gmp
by Christian Maeder 16 Apr '08

16 Apr '08

I understand that gmp is needed for the certain libraries like the Prelude with Double and Integer. But I do not understand why gmp is so deeply buried in the rts. Are the basic types Int and Pointer not enough to write a compiler like ghc? Cheers Christian

7 10

Internships at GHC HQ
by Simon Peyton-Jones 09 Feb '08

09 Feb '08

Would you be interested in working at Microsoft Research for three months? If so, you might want to think about applying for an internship. Simon and I are looking for interns, starting in summer 2008. Lots of background info here: http://hackage.haskell.org/trac/ghc/wiki/Internships including a bunch of possible projects, although you may also have ideas of your own. But the bottom line is - apply by end Feb 2008 for this round - tell one of us that you have done so (None of this is restricted to Haskell stuff. You can apply to work at any Microsoft Research lab, on any topic. But there are a lot of applicants, so you are more likely to be successful if you are fairly specific about who at MSR you'd like to work with and why, and contact that person to say that you've applied.) Simon

2 1

What does unsafePerformIO do to the stack
by Bernd Brassel 08 Feb '08

08 Feb '08

Consider the following program: module Stack where import System.IO.Unsafe main = print (sim (replicate 1299959 ())) sim [] = True sim (_:xs) = goodStack (sim xs) goodStack x = fromJust (Just x) --no stack overflow badStack x = unsafePerformIO (return x) --stack overflow fromJust (Just x) = x I always thought that unsafePerformIO would do something similar as goodStack. i.e. be stack neutral: $ ghc --make -o stack Stack [1 of 1] Compiling Main ( Stack.hs, Stack.o ) Linking stack ... $ stack +RTS -K0.00001M True But if you exchange goodStack with badStack, the picture changes unfortunately to: $ ghc --make -o stack Stack [1 of 1] Compiling Main ( Stack.hs, Stack.o ) Linking stack ... $ stack +RTS -K9.883647M Stack space overflow: current size 9883644 bytes. Use `+RTS -Ksize' to increase it. $ stack +RTS -K9.883648M True I am using: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 Is this behaviour necessary? Is there any work around, e.g., employing the foreign function interface? Thanks for your time! Bernd

2 8

Bootstrapping for Leopard
by Philip K.F. Hölzenspies 04 Feb '08

04 Feb '08

Dear All, I'm trying toupdate the Portfile so that ghc-6.8.2 can be built using MacPorts (handy for installing other ghc-dependent material from MacPorts like gtk2hs). The problem seems to be that the available bootstrap binary http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-apple-darwin-bootstrap.tar… causes a segfault on Leopard (below are the steps I took in my attempt to build ghc with this bootstrap binary). Using Manuel Chakravarty's binary distribution of ghc-6.8.1-i386-apple-darwin building ghc-6.8.2 works fine. It seemed to me that the easiest way to fix the bootstrap problem is to boot from C as described on the wiki (http://hackage.haskell.org/trac/ghc/wiki/Building/Porting) Two things were wrong, however. make hc-file-bundle Making the hc-file-bundle target failed, because not all rts/*.cmm had rts/*.hc counterparts after the build. The make fails because of this fragment from the Makefile (part of the hc-file-bundle target, starting from line 513): for f in `$(FIND) ghc-$(ProjectVersion)/compiler ghc-$(ProjectVersion)/rts -name "*.cmm" -follow -print` ""; do \ if test "x$$f" !=3D "x"; then \ echo `echo "$$f" | sed 's/cmm$$/hc/g' ` >> hc-files-to-go ; \ fi; \ done; This adds some non-existing .hc files to the hc-files-to-go list that tar will not find, later on, causing an error. I just added a test to see whether the file exists. If it does not, I call make for that .hc file explicitly, which solves the problem for most files. The files that don't have a make target, I simply omitted from the hc-files-to-go. I haven't been able to test the severity of this, because of the second problem. sh -e ./distrib/hc-build --prefix=3D$HOME/src/testbuild [--enable-hc-boot [--enable-hc-boot-unregisterised]] As a minor bug wrt. the wiki page, the hc-build is not executable by default. The more serious problem seems to be that the cold-boot option of configure is broken, because it ends in the error: checking for ld... /usr/bin/ld checking for path to top of build tree... ./configure: line 2651: -v0: command not found ./configure: line 2655: utils/pwd/pwd: No such file or directory configure: error: cannot determine current directory Upon inspection of the configure script, I found out that line 2651 uses the variable designating the ghc compiler. Are these bugs or am I messing things up? Regards, Philip

6 9

Is GHC 6.8.2 on solaris 32 bits or 64 bits
by hsing-chou chen 04 Feb '08

04 Feb '08

Thank you for porting GHC 6.8.2 to solaris, I am assigned a job to make sure GHC run 64 bits on solaris. Is your solaris port 64 bits. Or it only 32 BITS. I know 32 bits GHC can still run on 64 bits solaris. However company want to run really 64 bits GHC on solaris. Thanks a lot if you can give me feedback. Sincerely, Hsing-chou chen

3 4

A suggestion for GHC download pages
by Albert Y. C. Lai 03 Feb '08

03 Feb '08

On GHC version-specific download pages (e.g., http://www.haskell.org/ghc/download_ghc_682.html) under Source Distribution, it would reduce a major confusion of the form "I built GHC from source, now I use it, it says Network.CGI not found" if after the filename ghc-6.8.2-src.tar.bz2 it is also said "compiler and almost no libraries", and after the filename ghc-6.8.2-src-extralibs.tar.bz2 it is also said "most libraries, but it takes hours to build, Hackage has them piecemeal and more". Perhaps it would also be nice to say how to use the latter, e.g., "unpack this over the compiler source before building, before even building the compiler". Does it need to be said? Seems to be yes according my experience in #haskell. Here is how it can be misunderstood. Given the word "extralibs" and the file sizes, and no other words, what would an outsider think? Between the disproportionate 7MB and 2MB, 7MB must be because all the popular libraries are there, 2MB must be because "extralibs" means fringe, niche libraries. There lies the misunderstanding. Isn't it already said in the build guide? Yes it is, but the path between the download page and the build guide is not obvious. There is mention of the build guide, but it is put under the precondition "if your platform is not supported". IMO there should be no precondition; absolutely everyone building from source should be tempted to see the build guide. Perhaps the source section should also be close to the bottom of the download page, not to the top, reflecting what we recommend for most people.

3 2

Deforesting edtiInt
by Robin Houston 03 Feb '08

03 Feb '08

Recently I wrote a short program that builds an array containing the number of divisors of the first 10^7 natural numbers. (Some of you can guess why I did this, but I won't say explicitly lest this post become a Googleable spoiler.) Here's the relevant part of the code. incElem a i = readArray a i >>= \n -> writeArray a i $! n+1 do -- Create an array with elements initialised to 0 a <- newArray (1,n) 0 :: ST s (STUArray s Int Word16) -- Populate the array forM_ [2..n] $ \i -> forM_ [i, i+i .. n] (incElem a) Of course there are more efficient algorithms for this, but this one has the merit of being extremely simple without being unreasonably slow. Except that it is a lot slower than it needs to be. After digging around a bit, I suspected that the reason for this is that the general form of enumeration [from, then .. to] does not benefit from the deforestation optimisation. When I added some deforestation rules to GHC/Enum.lhs and rebuilt the library, I found my suspicion confirmed: after the change, my code runs roughly twice as fast. Is there any reason not to do this? I attach a diff of the change I made, though I expect it could be done better by someone with experience of this sort of thing. Robin

2 1