- Haskell-Cafe - Haskell.org

ICFP 2012: Call for participation
by Wouter Swierstra 02 Jul '12

02 Jul '12

===================================================================== Call for Participation The 17th ACM SIGPLAN International Conference on Functional Programming (ICFP 2012) and affiliated events http://www.icfpconference.org/icfp2012/ Copenhagen, Denmark, Sep 9-15, 2012 ===================================================================== ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. A full week dedicated to functional programming: 1 conference, 1 symposium, 9 workshops, 8 tutorials, programming contest results, student research contest * Accepted Papers: http://www.icfpconference.org/icfp2012/accepted.html * Local arrangements (including travel and accommodation): http://icfpconference.org/icfp2012/local.html Conference hotel reservation cutoff: July 9, 2012 * Registration is available via: http://icfpconference.org/icfp2012/ Electronic registration will open shortly. * Follow @icfp_conference on twitter for the latest news: http://twitter.com/#!/icfp_conference There are several events affiliated with ICFP: September 9 Workshop on Cross-paradigm Language Design and Implementation Workshop on Generic Programming Workshop on Higher-Order Programming with Effects Workshop on Logical Frameworks and Meta-languages: Theory and Practice September 10-12 ICFP - main conference September 13 Commercial Users of Functional Programming – Day 1 (CUFP Tutorials) Haskell Symposium Workshop on ML September 14 Commercial Users of Functional Programming – Day 2 (CUFP Tutorials) Erlang Workshop Haskell Implementors' Workshop OCaml Users and Developers Workshop September 15 Commercial Users of Functional Programming – Day 3 (CUFP Talks) Workshop on Functional High-Performance Computing Tutorial on Compiler Construction in Haskell Tutorial on the Grammatical Framework Conference organizers: * General Chair: Peter Thiemann, University of Freiburg * Program Chair: Robby Findler, Northwestern University * Local Arrangements Chair: Fritz Henglein, University of Copenhagen * Industrial Relations Chair: Andy Adams-Moran, Galois * Workshop Co-Chairs: Patrik Jansson, Chalmers University of Technology Gabriele Keller, University of New South Wales * Programming Contest Chair: Edwin Brady, University of St. Andrews Kevin Hammond, University of St. Andrews * Publicity Chair: Wouter Swierstra, Utrecht University * Video Chair: Malcolm Wallace, Standard Chartered Bank * Student Research Competition Chair: Doaitse Swierstra, Utrecht University =====================================================================

1 0

not enough fusion?
by Johannes Waldmann 02 Jul '12

02 Jul '12

Dear all, while doing some benchmarking (*) I noticed that function s1 is considerably faster than s2 (but I wanted s2 because it looks more natural) (for n = 10000, s1 takes 20 s, s2 takes 13 s; compiled by ghc-7.4.2 -O2) s1 :: Int -> Int s1 n = sum $ do x <- [ 0 .. n-1 ] return $ sum $ do y <- [ 0 .. n-1 ] return $ gcd x y s2 :: Int -> Int s2 n = sum $ do x <- [ 0 .. n-1 ] y <- [ 0 .. n-1 ] return $ gcd x y I was expecting that in both programs, all lists will be fused away (are they?) so the code generator essentially can produce straightforward assembly code (no allocations, no closures, etc.) For reference, I also wrote the equivalent imperative program (two nested loops, one accumulator for the sum) (with the straightforward recursive gcd) and runtimes are (for same input as above) C/gcc: 7.3 s , Java: 7.7 s, C#/Mono: 8.7 s So, they sort of agree with each other, but disagree with ghc. Where does the factor 2 come from? Lists? Laziness? Does ghc turn the tail recursion (in gcd) into a loop? (gcc does). (I am looking at -ddump-asm but can't quite see through it.) (*) benchmarking to show that today's compilers are clever enough such that the choice of paradigm/language does not really matter for this kind of low-level programming.

7 8

package to expand TH macros?
by Eric 01 Jul '12

01 Jul '12

I seem to remember finding a package a few days ago that would take Haskell source with TH, then run and expand the TH macros in-place to produce equivalent, TH-free Haskell source. I just went through the Hackage package list and didn't find anything like that. Did I imagine it? Or can anyone remind me its name? thanks, --Eric

3 2

ANN: wizards-1.0: A High level, generic library for interrogative user interfaces
by Liam O'Connor 01 Jul '12

01 Jul '12

Hi all, wizards is an Haskell library designed for the quick and painless development of interrogative programs, which revolve around a "dialogue" with the user, who is asked a series of questions in a sequence much like an installation wizard. Everything from interactive system scripts, to installation wizards, to full-blown shells can be implemented with the support of wizards. It is developed transparently on top of a free monad (see Swierstra's excellent paper on this topic at http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCarte.pdf) which separates out the semantics of the program from the wizards interface. A variety of backends exist, including a full featured backend for Haskeline, a debug-friendly simpler implementation in terms of System.IO primitives, and a completely pure implementation modelled as a function from an input string to output. It is also possible to write your own backends, or extend the existing back-ends with new features. While both built-in IO backends operate on a console, there is no reason why wizards cannot also be used for making GUI wizard interfaces. The library is highly extensible - back-ends can be written or extended with the type system helpfully tracking what features are supported by which back-ends. Installation instructions and some educational examples are at the github page: https://github.com/liamoc/wizards Information on how to write backends or extend backends, as well as structured API documentation is available on Hackage: http://hackage.haskell.org/package/wizards (Or, you can just run cabal haddock to generate the documentation from the source). Regards, Liam O'Connor

3 3

ANN: prof2pretty-0.1.0.0
by Claude Heiland-Allen 30 Jun '12

30 Jun '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I wanted to try visual-prof[1] but found it was broken by ghc RTS changes[2]. I ended up writing prof2pretty[3]: http://hackage.haskell.org/package/prof2pretty - --8<-- sccpragmabomb adds SCC pragmas encoding source location. prof2pretty extracts those SCCs from the profiling output to annotate the sources using HTML + CSS + JavaScript. - --8<-- [1] http://hackage.haskell.org/package/visual-prof [2] http://hackage.haskell.org/trac/ghc/ticket/4094 [3] prof2pretty started as a fork of visual-prof but soon there was none of the original code left, though the essential concept remains the same Thanks, Claude -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJP7wPyAAoJEHZDo4jueIiW7WsH/3Lmk2k7o+2i5u+Vxn+EZXRX 5XRDXZ8mLm1NBb/OSfRFr6RIyZxwou8JeavZJuhqOBL38KAlppf89OnaJyxUB+ap Cp03ui/1LbihqIbMxupNH03pQwkNR7b2MV2S07c5TOvOJHsksE53zEin/EHQQ6jO 6QxrQdNibjSYlXDNtZCzEj0HWVpSBD4gXdPFv9nFS+RKPjAkgC4gmY4yItYDep60 qboOrxKVhYJdqTmhl+OXhe7LAAJ9Nc3xiheGLbeyTfH2owAnT8X4zOdtssOsPPdm AQBgxKa8p5KckZCKS7Elj8pap9uzUHGc8KuINpjx40b7envHP44t65xngEq1TaU= =znB1 -----END PGP SIGNATURE-----

1 0

Maintainer of pngload listening?
by Daniel Trstenjak 30 Jun '12

30 Jun '12

Hi, Marko Lauronens email address from the package is invalid, so I'm trying to reach him this way. pngload doesn't compile with ghc >= 7.2 because of it's dependency to base and haskell98. Greetings, Daniel

3 3

Slowdown with GHC when using multiple CPUs
by David Powell 29 Jun '12

29 Jun '12

I recently ran into a problem writing a program that I hoped I could speed up by running over multiple CPUs. I want non-haskell users to be able to run the tool and take advantage of multiple CPUs. *But* there is a serious slowdown when the RTS is run with -N and some of the CPUs are already busy. This is already mentioned in the GHC docs, but the problem I experienced was more serious than I expected causing a slowdown of around 2x compared to running with a single CPU. I reproduced the problem with the following code from the haskell wiki: {-# LANGUAGE BangPatterns #-} import Data.Digest.Pure.MD5 import qualified Data.ByteString.Lazy as L import System.Environment import Control.Concurrent import Control.Monad (replicateM_) main = do files <- getArgs str <- newEmptyMVar mapM_ (forkIO . hashAndPrint str) files printNrResults (length files) str printNrResults i var = replicateM_ i (takeMVar var >>= putStrLn) hashAndPrint str f = do bs <- L.readFile f let !h = show $ md5 bs putMVar str (f ++ ": " ++ h) When run on 4 idle CPU cores, I get the following wall clock times: ./run +RTS -N1 : 20.4 sec ./run +RTS -N2 : 11.0 sec ./run +RTS -N4 : 6.7 sec When run on the same 4 core machine, but with 2 cores already busy: ./run +RTS -N1 : 23.5 sec ./run +RTS -N2 : 14.1 sec ./run +RTS -N4 : 57.8 sec <---- Blowout... This is quite a problem in practice when running on a shared server. Is there anything that can be done to address this? (I wrote up a few more details here: http://thunking.drp.id.au/2012/06/slowdown-with-ghc-when-using-multiple.html ) Thanks, -- David Powell

2 1

Help requested: naming things in conduit
by Michael Snoyman 28 Jun '12

28 Jun '12

Hi all, I'm just about ready to make the 0.5 release of conduit. And as usual, I'm running up against the hardest thing in programming: naming things. Here's the crux of the matter: in older versions of conduit, functions would have a type signature of Source, Sink, or Conduit. For example: sourceFile :: MonadResource m => FilePath -> Source m ByteString I think most people can guess at what this function does: it produces a stream of ByteStrings, which are read from the given file. Now the trick: Source (and Sink and Conduit) are all type synonyms wrapping around the same type, Pipe. Ideally, we'd like to be able to reuse functions like sourceFile in other contexts, such as producing a Conduit that calls sourceFile[1]. However, the type synonym Source over-specifies some of the type parameters to Pipe, and therefore `sourceFile` can't be used directly to create a Conduit[2]. To get around this whole problem, I've added a number of type synonyms with rank-2 types, that don't over-specify. You can see the type synonyms here[3], and more explanation of the problem here[4]. So my question is: can anyone come up with better names for these synonyms? Just to summarize here: * All of the generalized types start with a G, e.g., Source becomes GSource. * For Sinks and Conduits, if leftovers are generated, there's an L after the G (e.g., GLSink). * For Sinks and Conduits which consume all of their input and then return the upstream result, we tack on an Inf for Infinite (e.g., GInfConduit, GLInfSink). I think these names are relatively descriptive, and certain `GSink ByteString m Int` is easier to follow than `Pipe l ByteString o u m Int`, but I was wondering if anyone had some better recommendations. Michael [1] For example, maybe we want to produce `conduitFiles :: MonadResource m => Conduit FilePath m ByteString` [2] This problem exists to a smaller extent in conduit 0.4. This is the purpose of the sinkToPipe function. [3] https://github.com/snoyberg/conduit/blob/52d7bc0b551b877de92be4c87f933e3ffb… [4] https://github.com/snoyberg/conduit/blob/a853141d7b9eed047c7cc790979f73a346…

2 2

crash in hs_init_ghc
by A.M. 28 Jun '12

28 Jun '12

Hello, I am trying to load a Haskell module in a C program as a dynamically-loaded plugin via FFI. I am able to compile and link successfully, but I find the following crash. #0 0x00007f16147da9e7 in ?? () from /usr/lib/ghc/libHSrts_debug-ghc7.4.1.so #1 0x00007f16147e0970 in hs_init_ghc () from /usr/lib/ghc/libHSrts_debug-ghc7.4.1.so #2 0x00007f16147e0795 in hs_init () from /usr/lib/ghc/libHSrts_debug-ghc7.4.1.so #3 0x00007f1614a44ece in plhaskell_plmain (fcinfo=<optimized out>) at plhaskellc.c:26 #4 0x0000000000565e1a in ExecMakeFunctionResult () #5 0x00000000005682f2 in ExecProject () #6 0x000000000057849a in ExecResult () #7 0x0000000000561648 in ExecProcNode () #8 0x000000000055ea5a in standard_ExecutorRun () #9 0x0000000000628577 in PortalRunSelect () #10 0x0000000000629900 in PortalRun () #11 0x0000000000625bec in PostgresMain () #12 0x00000000005eb429 in ServerLoop () #13 0x00000000005ebd3c in PostmasterMain () #14 0x0000000000453d20 in main () In the trace above, one can see that I am linking against the debugging Haskell runtime. hs_init_ghc is called with dual NULL arguments. Is that cause for concern? I noticed that RtsStartup.c does some questionable stuff in a module context right away, such as calling "setlocale". Are there other things I need to watch out for? Do I need to build ghc from source in order to debug this further? Any advice would be appreciated. This is on Ubuntu 12.04. Cheers, M

1 0

Network.Curl curiosity
by Michael Orlitzky 28 Jun '12

28 Jun '12

I've been fighting with this silly bug: I have two functions using curl (Network.Curl) for logging in via POST and downloading pages via GET. They do the usual boring stuff; cookies go in a text file whose path is passed in to both functions. They work great individually. But, I'm calling them sequentially: cj <- make_cookie_jar li_result <- log_in cj username password html <- get_page (Just cj) my_article The symptom that I noticed was that the call to get_page wasn't using the cookies. I looked in the cookie file -- they're all there. And when I call get_page from ghci (with the same cookie file), it works. It turns out that between the calls to log_in and get_page, the cookie file is empty. The stupidest possible solution that works is, cj <- make_cookie_jar li_result <- log_in cj username password putStrLn "Waiting one second..." thread_sleep 1 html <- get_page (Just cj) my_article And this program is not at all time sensitive, so that actually works for me. But now I'm curious. Does anyone have an idea what sort of sorcery is going on? Here's the rest of log_in if it's useful. log_in :: FilePath -> String -> String -> IO Bool log_in cookie_jar username password = withCurlDo $ do -- Create a curl instance. curl <- initialize -- Perform the request, and get back a CurlResponse object. -- The cast is needed to specify how we would like our headers -- and body returned (Strings). resp <- do_curl_ curl login_url curl_opts :: IO CurlResponse -- Pull out the response code as a CurlCode. let code = respCurlCode resp case code of CurlOK -> return True error_code -> do hPutStrLn stderr ("HTTP Error: " ++ (show error_code)) -- If an error occurred, we want to dump as much information as -- possible. If this becomes a problem, we can use respGetInfo -- to query the response object for more information return False where post_submit :: String post_submit = submit_field ++ "=Log+In" post_username :: String post_username = username_field ++ "=" ++ username post_password :: String post_password = password_field ++ "=" ++ password post_data :: [String] post_data = [post_username, post_password, post_submit] post_opts :: [CurlOption] post_opts = [ CurlCookieSession True, CurlCookieJar cookie_jar, CurlPost True, CurlPostFields post_data ] curl_opts :: [CurlOption] curl_opts = default_curl_opts ++ post_opts default_curl_opts :: [CurlOption] default_curl_opts = [ -- The Global cache is not thread-friendly. CurlDNSUseGlobalCache False, -- And we don't want to use a DNS cache anyway. CurlDNSCacheTimeout 0, -- Follow redirects. CurlFollowLocation True, -- Give it a little time... CurlTimeout 45, -- For debugging. CurlVerbose True ]

1 0