- Glasgow-haskell-users

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

Will implicit parameters survive?
by Wolfgang Jeltsch 07 Feb '08

07 Feb '08

Hello, what are the plans for implicit parameters? Will GHC continue to support them or could it be that they will be removed at some time? I think that implicit parameters can be very useful for implementing global variables as described in <http://www.cs.chalmers.se/~rjmh/Globals.ps>. Surprisingly, the interest in implicit parameters seems to be rather low as the GHC survey from 2005 suggests. Despite this, I’d propose that support for implicit parameters continues. But what do the GHC developers think? Best wishes, Wolfgang

3 2

Re: GHC armel port for N810
by Dustin DeWeese 07 Feb '08

07 Feb '08

Martin, I was able to make an unregisterised port of GHC 6.8.2 to the N810 by using Scratchbox with the qemu-arm-eabi patch[1]. Have you started on a registerised port? I have been reading the ARM Architecture Reference Manual and other documents about the ARM ABI, and I am working on a registerised port of GHC for the N810. [1] http://maemogeek.blogspot.com/2007/11/installing-qemu-arm-eabi-patch-into.h… On Jan 23, 2008 7:32 AM, Martin Guy <martinwguy(a)yahoo.it> wrote: > > I've been working on porting GHC to armel for the Nokia N810. > > Unfortunately, I can't use the packages you made because the OS > > (maemo.org) is based on Debian Sarge and uses libc-2.5. I'm using > > scratchbox (scratchbox.org) and qemu and following the instructions at > > http://hackage.haskell.org/trac/ghc/wiki/Building/Porting , but have > > been unsuccessful. The stage1 compiler compiles fine, but then crashes > > when building the stage2 compiler on qemu. I've tried GHC 6.4.2, 6.6.1, > > and 6.8.2, but 6.6.1 is the version I get furthest with. Is there any > > tips you can give me? Do you still have the intermediate .hc files from > > your builds? (The .hc files built on a ARM might work better.) Did you > > have similar problems with qemu? > > I used a fast x86 to make the .hc files, as documented in the URL you > cite, > then did the final build on a lot of real ARMs. The problem is it > needs over 128MB RAM (yes, RAM) to compile some of the files - I did > these few under QEMU. My personal notes are attached - these are not a > product, they are my own personal notes, so please don't expect them > to be a how-to. Porting GHC was difficult and not straightforward, > dying at many stages for many different reasons. > > The real answer is for Maemo to update its software to versions from > this century. > I did this in 2006 trying to bootstrap the Debian arm EABI port and my > notes are at > http://cluster.aleph1.co.uk/~martin/maemo-fixes.txt<http://cluster.aleph1.co.uk/%7Emartin/maemo-fixes.txt> > > For further help with this, I suggest we find a mailing list where > others can give their expertise and experience, and where in future > people will find the outcome of our discussion. How about > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ? > > Good luck! > > M >

1 0

GHC lazy eval optimization bug
by Adam P Jenkins 05 Feb '08

05 Feb '08

The haskell program below demonstrates an optimization bug with the GHC compiler. I have tried this with ghc 6.8.1 on my MacBook Pro and on a Linux i686 machine. This email should build as a literate haskell program. Build the program as ghc --make -O lazyevalbug.lhs and run it with no arguments. An IO action runs 4 times, printing out how long it took each time. It takes 1 to 2 seconds to run each time, but it should only take 1 second or 2 the first time, and finish almost instantaneously the rest of the times. If you run the program with "fast" as a cmdline arg, as in ./lazyevalbug fast then it will behave how I'd expect it to: the first IO action takes a couple of seconds tand the rest finish instantaneously. If you build the program without the -O switch, then it behaves the same with our without the "fast" commandline arg. DETAILS: The bug involves lazy evalutation behaving in an unexpected way when the program is compiled with the -O switch. If I create an IO action which refers to a variable which was defined outside of the IO action, and then run that IO action multiple times, then in some circumstances the variable value will be re-computed each time the IO action is run. This seems to violate the behavior I expect from lazy evaluation. I.e. if I have code like this: let val = really_expensive_computation in map (\x -> val + x) [1, 2, 3] I would expect val to only be computed once. And it is. However if instead of referring to val in a lambda function I refer to val from an IO action, then in some cases it seems to be re-evaluated every time the action is performed. I.e. let val = really_expensive_computation in replicateM_ 3 (print val) When compiled with -O, the above will recompute val 3 times. However adding a second reference to "val" seems to make the problem go away. Another thing I noticed is, the problem seems to only occur if really_expensive_computation involves the IO monad somehow, for example if it's doing a computation based on some input read from stdin. If really_expensive_computation only involves data generated within the program then the bug never occurs. The program below demonstrates this problem with the doSlow and doFast functions. See the comment above these functions. Also, in main, if you comment out the getStdGen line and uncomment the mkStdGen line, then the problem goes away. This demonstrates the fact that if the computation uses data from an IO action the problem occurs, otherwise it doesn't. > import System (getArgs) > import qualified System.Time as ST > import Control.Monad (when, replicateM_) > import System.Random (getStdGen, mkStdGen, randoms) Takes an IO action, runs it, and prints line saying how long it took to run > timeIt :: IO a -> IO () > timeIt action = > do tic <- ST.getClockTime > action > toc <- ST.getClockTime > putStrLn $ "Took " ++ (timeDiffToString (ST.diffClockTimes toc tic)) > -- System.Time.timeDiffToString doesn't handle fractions of a > -- second correctly, so I implement my own version > where timeDiffToString d = > let secs = ST.tdMin d * 60 + ST.tdSec d > frac = (realToFrac $ abs $ ST.tdPicosec d) / (realToFrac $ 10^12) > in show ((realToFrac secs) + frac) ++ " secs" True if a number is prime. Just a function meant to use up some time > isPrime :: (Integral n) => n -> Bool > isPrime n = > let lim = round (sqrt $ realToFrac n) in > not $ any (\x -> n `rem` x == 0) [2..lim] doSlow and doFast are exactly the same, except that doFast has an extra "when" statement which references "primes". The mere existence of this extra reference to "primes" in doFast seems to cause the primes list to only be generated once, so the first time action runs takes around 1.6 seconds, but subsequent actions finish in a small fraction of a second. In doSlow, the action takes 1.6 seconds each time it runs, not just the first time, indicating that primes is getting re-created each time the action is run. > doSlow, doFast :: (Integral a) => [a] -> IO () > doSlow lst = let primes = filter isPrime lst > action = timeIt $ print (length primes) > in do replicateM_ 4 action > doFast lst = let primes = filter isPrime lst > action = timeIt $ print (length primes) > in do replicateM_ 4 action > when (null primes) (print "No primes") In main, comment out the getStdGen line and uncomment the mkStdGen line and the problem goes away as well. The same is true if I read data from stdin vs generating a list in memory. > main = do args <- getArgs > let doFunc = if (length args) > 0 && args!!0 == "fast" > then doFast > else doSlow > --gen <- return $ mkStdGen 42 > gen <- getStdGen > let lst = take 10000 $ randoms gen :: [Integer] > doFunc lst

5 6

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

1st call for participation AFP 2008, The Netherlands
by Peter Achten 04 Feb '08

04 Feb '08

1ST CALL FOR PARTICIPATION 6TH INTERNATIONAL SUMMER SCHOOL ON ADVANCED FUNCTIONAL PROGRAMMING 2008 (AFP ’08) RADBOUD UNIVERSITY NIJMEGEN AND UTRECHT UNIVERSITY, THE NETHERLANDS MAY 19-24, 2008 http://www.st.cs.ru.nl/AFP_TFP_2008/ AFP is a series of international summer schools which aims to bring computer scientists, in particular young researchers and programmers, up to date with the latest advances in practical advanced functional programming. Functional programming emphasizes the evaluation of expressions rather than the execution of commands. We focus on functional programming techniques in “programming in the real world” and bridge the gap between results presented at programming conferences and material from textbooks on functional programming. In this school you will receive in depth lectures about advanced functional programming techniques, taught by experts in the field. Lectures are accompanied by practical problems to be solved by the students at the school. AFP 2008 is hosted by the Radboud University Nijmegen, and Utrecht University, The Netherlands, and will be held in the rural setting of Center Parcs “Het Heijderbos”, Heijen (in the vicinity of Nijmegen), The Netherlands. AFP 2008 is co-located with the 9th Symposium on Trends in Functional Programming (TFP’08), which is held after AFP’08. PROGRAM INFORMATION The following speakers will give the lectures (in alphabetic order): Umut Acar (Toyota Technological Institute, University of Chicago, US) Richard Bird (University of Oxford, UK) Olivier Danvy (University of Aarhus, DK) Johan Jeuring (Utrecht University, NL) Mark Jones (Portland State University, US) Ulf Norell (Chalmers University, SE) Simon Peyton Jones (Microsoft Research, UK) Rinus Plasmeijer (Radboud University Nijmegen, NL) During the summer school, all participants receive printed lecture notes. Participants are expected to have a notebook, in order to be able to participate with the practical problems. After the summer school, all lecture notes will be revised, reviewed, and published in the LNCS series of Springer. All registered participants receive a copy of these lecture notes. VENUE INFORMATION AFP (and TFP) is held in The Netherlands, at Center Parcs “Het Heijderbos” which is a holiday resort in the woodlands near the city of Nijmegen. We accomodate participants in DeLuxe Cottages, each of which has three separate bed-rooms, shared bathroom, toilet, kitchen, and terrace. Cottages will be shared by three participants. If you wish to reduce costs, you can choose to share a bedroom. The summer school and symposium will take place in the business center of the venue. Breakfast, lunch and diner is included within the limits of the venue. The resort features, amongst others, a sub-tropical swimming pool (free for participants), restaurants, shops, water sports lake, midget golf court, squash court, and outdoor and indoor tennis courts. Nijmegen is considered to be the oldest city of the Netherlands, being approximately 2000 years old. Nijmegen is located at the east border of the Netherlands, near Germany. Nijmegen can be reached easily from several airports such as Schiphol airport, Eindhoven airport, and Düsseldorf airport, as well as by train and car. Conveniently close to Center Parcs “Het Heijderbos” you will find airport Weeze in Germany. The venue Center Parcs “Het Heijderbos” can be reached from Nijmegen by train to Boxmeer (25 minutes). From there you will need to order a taxi. The venue can also be reached by car: parking is free for participants of AFP and TFP. SUMMER SCHOOL FEES AFP 2008 includes accommodation, conference, breakfast – lunch – diner, speakers, and proceedings costs. The early registration fee is € 995; the late registration fee is € 1095. Please note that if you require financial support, you can apply for a grant (see below). GRANT INFORMATION We have taken great care to reduce the registration cost as much as possible. We can grant a subsidy for a limited number of PhD student participants for whom the costs are still too high. In order to apply for this subsidy, you need to send (by surface mail or e-mail) a request for subsidy which contains your personal information, affiliation, a description of your current status, project description, a motivation why you should receive the grant, and a recommendation from your PhD supervisor. This letter should arrive before april 7 2008 to: Rinus Plasmeijer Radboud University Nijmegen Toernooiveld 1 6525ED Nijmegen rinus(a)cs.ru.nl You will receive a notification whether your request has been granted before april 14 2008. REGISTRATION INFORMATION Early registration opens at march 1 2008. Late registration opens at april 15 2008. Registration closes at may 5 2008. We can not guarantee accommodation in case you wish to register later than may 5 2008. IMPORTANT DATES (ALL 2008) Early Registration Opens: March 1 Early Registration Deadline: April 14 Late Registration Opens: April 15 Late Registration Deadline: May 5 AFP Summer School: May 19-24 ORGANIZATION Programme Chair: Rinus Plasmeijer, Pieter Koopman, Radboud University Nijmegen, NL Doaitse Swierstra, Utrecht University, NL Arrangements: Peter Achten, Simone Meeuwsen, Radboud University Nijmegen, NL E-mail: afp_tfp_2008(a)cs.ru.nl

1 0

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