- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Empty Input list
by Kevin Clees 13 Mar '12

13 Mar '12

Hey Chris, thank you for your help! Your last comment with the (!!)-thing was a very good idea! Now my function looks like this: tmp:: [(Int, Int)] -> Int -> (Int, Int) tmp [] y = (0,0) tmp xs y = xs !! (y-1) If the function returns (0,0) it will blocked by another function. If I want to use the "maybe" return, I get some new trouble that I don't like - so I chose that way :) Thank you again Kevin

5 4

Leksah Install Issue (cabal experts please help)
by Hamish Mackenzie 13 Mar '12

13 Mar '12

pozic raised an install issue on IRC. Basically he was getting... ~$ cabal install leksah-server Resolving dependencies... cabal: Couldn't read cabal file "leksah-server/0.12.0.3/leksah-server.cabal" To reproduce this issue. Use GHC 6.12.3, 7.0.3 or 7.2.2 to "cabal install cabal-install" then run "cabal install leksah-server". To work around it install GHC 7.0.4 or 7.4.1 and use it to run "cabal install cabal-install" (then you can go back to the old GHC if you want). Cabal experts, is there a better work around than this? The current leksah-server.cabal requires Cabal 1.10.2 or greater because it has a "test-suite" section for "cabal test". This is fine if you have installed cabal-install with GHC 7.0.4 or 7.4.1, but if you install cabal-install with older versions of GHC (including 7.2.2) then it can't handle the file format. I could upload a new leksah-server to hackage (with the unit tests removed), but that would not stop cabal-install from failing to read leksah-server 0.12.0.3 and bombing out (there is already a 0.12.0.4 and it is not getting to that one). Even if you "cabal unpack" and then modify the .cabal file and run "cabal install" it still fails with the same error. If you can think of a better solution than asking users to install GHC 7.0.4 or 7.4.1 to build cabal-install, then please let me know.

2 7

Empty Input list
by Kevin Clees 12 Mar '12

12 Mar '12

Dear Haskell friends, what can I do, if a function gets an empty input list? I want, that it only returns nothing. This is my source code: tmp:: [(Int, Int)] -> Int -> (Int, Int) tmp (x:xs) y | y == 1 = x | y > 1 = tmp xs (y-1) If this function gets an empty list, he throws "Exception: sortAlgo.hs:(18,1)-(21,44): Non-exhaustive patterns in function Main.tmp" *Main> tmp [(1,2),(3,2)] 1 (1,2) *Main> tmp [(1,2),(3,2)] 2 (3,2) *Main> tmp [] 1 *** Exception: sortAlgo.hs:(20,1)-(22,44): Non-exhaustive patterns in function Main.listElementIntInt Thank you for any help ! Best regards Kevin

2 2

Re: [Haskell-cafe] IO() and other datatypes
by Kevin Clees 12 Mar '12

12 Mar '12

Great, Thank you !

1 0

Helper classes for Generics
by Reiner Pope 12 Mar '12

12 Mar '12

Hi all, I've been playing with GHC's new generics features (see http://www.haskell.org/ghc/docs/latest/html/users_guide/generic-programming…) All the documentation I've seen suggests creating a "helper class" -- for instance, the GSerialize class in the above link -- on which one defines generic instances. It seems to me that this isn't necessary. For example, here's the the example from the GHC docs, but without a helper class: > -- set the phantom type of Rep to (), to avoid ambiguity > from0 :: Generic a => a -> Rep a () > from0 = from > > data Bit = O | I > > class Serialize a where > put :: a -> [Bit] > > default put :: (Generic a, Serialize (Rep a ())) => a -> [Bit] > put = put . from0 > > instance Serialize (U1 x) where > put U1 = [] > > instance (Serialize (a x), Serialize (b x)) => Serialize ((a :*: b) x) where > put (x :*: y) = put x ++ put y > > instance (Serialize (a x), Serialize (b x)) => Serialize ((a :+: b) x) where > put (L1 x) = O : put x > put (R1 x) = I : put x > > instance (Serialize (a x)) => Serialize (M1 i c a x) where > put (M1 x) = put x > > instance (Serialize a) => Serialize (K1 i a x) where > put (K1 x) = put x Is there a reason to prefer using helper classes? Or perhaps we should update the wiki page (http://www.haskell.org/haskellwiki/Generics) to avoid using helper classes? Regards, Reiner

3 5

ANNOUNCE: pipes-core 0.0.1
by Paolo Capriotti 12 Mar '12

12 Mar '12

I'm pleased to announce the release of version 0.0.1 of pipes-core, a library for efficient, safe and compositional IO, similar in scope to iteratees and conduits. http://hackage.haskell.org/package/pipes-core This is a reimplementation of the original 'Pipe' concept by Gabriel Gonzales. The package documentation contains an introduction to Pipes and a detailed tutorial, so here I'll just outline some of the differences from the original version: - A single composition operator. "Strict" composition has been removed, since its role wasn't actually that clear, and its purpose for resource finalization has been replaced by better constructs (see below). - A new primitive 'tryAwait', which makes it possible to recover from termination of an upstream pipe. Using 'tryAwait' you can write pipes that are able to consume all their input and return a value (like iteratees or Conduit's sinks can), and stateful pipes that can make use of their final state before terminating. - Full exception safety and exception-handling primitives. Pipes have been augmented with 'catch' and 'finally' primitives, which allow you to recover from exceptions and ensure finalization of resources within the Pipe monad. There's no more need to use resource-simple or monadic regions together with Pipes. - Multi-channel pipes. This is a generalization of Arrows using sums instead of pairs for contexts. We provide a number of combinators that allow you to combine Pipes in much the same way as Arrows, although there is not unfortunately an alternative for the Arrow syntax. Together with pipes-core, I also released a number of accessory packages with various utilities. Here is a complete list: * pipes-extra: File readers and writers, chunk pipes. http://hackage.haskell.org/package/pipes-extra * pipes-attoparsec: Utilities to convert a parser into a pipe. http://hackage.haskell.org/package/pipes-attoparsec * pipes-conduit: Conduit adapters. http://hackage.haskell.org/package/pipes-conduit * pipes-network: Utilities to deal with sockets. Ported from conduit. http://hackage.haskell.org/package/pipes-network * pipes-zlib: Pipes to deal with zipped data. Ported from conduit. http://hackage.haskell.org/package/pipes-zlib This is an experimental release, but it should be equipped with all the functionality needed to write serious applications. I encourage people to try it out and send feedback if anything looks too simplistic or too limiting. BR, Paolo Capriotti

4 25

Global Arrays
by Clark Gaebel 12 Mar '12

12 Mar '12

In Haskell, what's the canonical way of declaring a top-level array (Data.Vector of a huge list of doubles, in my case)? Performance is key in my case. The straightforward way would just be something like: globalArray :: V.Vector Double globalArray = V.fromList [ huge list of doubles ] {-# NOINLINE globalArray #-} However, I don't want to have to run the fromList at runtime. Not only would this mean a bigger executable (having to store a linked list, instead of an array), it would be quite inefficient since we don't even use the source list! Therefore, I was thinking of storing the array in a C file: static const double globalArray[] = { huge list of doubles }; double* getGlobalArray() { return globalArray; } int getGlobalArraySize() { return sizeof(globalArray)/sizeof(globalArray[0]); } And importing it in haskell witht he FFI, followed with an unsafeCast: foreign import ccall unsafe "getGlobalArray" c_globalArray :: Ptr CDouble foreign import ccall unsafe "getGlobalArraySize" c_globalArraySize :: CInt globalArray :: V.Vector Double globalArray = V.unsafeCast $ unsafeFromForeignPtr0 (unsafePerformIO $ newForeignPtr_ c_globalArray) (fromIntegral c_globalArraySize) {-# NOINLINE globalArray #-} But this version (clearly) is full of "unsafe"ty. Is there a better way that I haven't thought of? Regards, - clark

5 8

Question about concurrency, threads and GC
by Paul Graphov 12 Mar '12

12 Mar '12

Hello Cafe! I am trying to implement networked application in Haskell. It should accept many client connections and support bidirectional conversation, that is not just loop with Request -> Response function but also sending notifications to clients etc. NB: I came from C++ background and used to explicit asynchonous operations and pools of OS threads. (Boost.Asio + Boost.Thread) There seem to be lots of goodies around (green threads, STM). The problem is that I cannot figure out how to design such applications. First of all now I have to start some threads for each client. Client state and behaviour may change depending on data that comes from it or other clients. So it seems that I have to start at least three threads: one that reads data from socket, one that sends queued messages to the socket and one that represents clients main behaviour loop. The last one will supposedly read from some STM sources, one of them being TChan/TMVar filled by thread that reads socket. Here I get stuck: how to manage that threads? I tried to search STM examples at hackage and the most interesting packages were: 1) combinatorrent - quite complex application, but it seem to be highly Erlang-inspired, so I am not sure that it is the simplest way of doing thing. 2) network-connection package - it is a library that wraps socket and uses STM internally but exposes almost the same interface with blocking operations. Thread management is quite explicit there. But this package is marked obsolete. I wondered if one can rely upon garbage collector to reap dead threads when using STM? Or is it too error prone (accidental references to STM object that prevent it from being collected) and unpredictable? I have read this post: http://blog.ezyang.com/2011/07/blockedindefinitelyonmvar/ It shows that relying upon handling BlockedIndefinitelyOn* exceptions is a bad idea but is it OK just to rely upon that blocked forever thread will die and not to kill it explicitly? And also if it is really reliable, what are exact rules when some object goes out of scope and becomes collectable? For example in blog post mentioned above in "main1" example "lock" variable is accessible until the end of do-block, i.e. if I add "takeMVar lock" line to its end, it will compile. But it is not used actually. Is it guaranteed that explicit performGC will reap it? Possibly the best answer would be just pointing me to some recent examples of concurrent network applications. Thanks!

5 9

Understanding GC time
by Thiago Negri 12 Mar '12

12 Mar '12

Hi all. I wrote a very simple program to try out parallel Haskel and check how it would look like to make use of more than one core in this language. When I tried the program with RTS option -N1, total time shows it took 2.48 seconds to complete and around 65% of that time was taken by GC. Then I tried the same program with RTS options -N2 and total time decreased to 1.15 seconds as I expected a gain here. But what I didn't expect is the GC time to drop to 0%. I guess I'm having trouble to understand the output of the RTS option -s. Can you enlighten me? The source for the testing program: > module Main where > > import Data.List (foldl1') > import Control.Parallel (par, pseq) > import Control.Arrow ((&&&)) > > f `parApp` (a, b) = a `par` (b `pseq` (f a b)) > seqApp = uncurry > > main = print result > where result = (+) `parApp` minMax list > minMax = minlist &&& maxlist > minlist = foldl1' min > maxlist = foldl1' max > list = [1..19999999] The results on a Windows 7 64bits with an Intel Core 2 Duo, compiled with GHC from Haskell Platform: c:\tmp\hs>par +RTS -s -N1 par +RTS -s -N1 20000000 803,186,152 bytes allocated in the heap 859,916,960 bytes copied during GC 233,465,740 bytes maximum residency (10 sample(s)) 30,065,860 bytes maximum slop 483 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 1523 collections, 0 parallel, 0.80s, 0.75s elapsed Generation 1: 10 collections, 0 parallel, 0.83s, 0.99s elapsed Parallel GC work balance: nan (0 / 0, ideal 1) MUT time (elapsed) GC time (elapsed) Task 0 (worker) : 0.00s ( 0.90s) 0.00s ( 0.06s) Task 1 (worker) : 0.00s ( 0.90s) 0.00s ( 0.00s) Task 2 (bound) : 0.86s ( 0.90s) 1.62s ( 1.69s) SPARKS: 1 (0 converted, 0 pruned) INIT time 0.00s ( 0.00s elapsed) MUT time 0.86s ( 0.90s elapsed) GC time 1.62s ( 1.74s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 2.48s ( 2.65s elapsed) %GC time 65.4% (65.9% elapsed) Alloc rate 936,110,032 bytes per MUT second Productivity 34.6% of total user, 32.4% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync_large_objects: 0 gen[1].sync_large_objects: 0 c:\tmp\hs>par +RTS -s -N2 par +RTS -s -N2 20000000 1,606,279,644 bytes allocated in the heap 74,924 bytes copied during GC 28,340 bytes maximum residency (1 sample(s)) 29,004 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 1566 collections, 1565 parallel, 0.00s, 0.01s elapsed Generation 1: 1 collections, 1 parallel, 0.00s, 0.00s elapsed Parallel GC work balance: 1.78 (15495 / 8703, ideal 2) MUT time (elapsed) GC time (elapsed) Task 0 (worker) : 0.00s ( 0.59s) 0.00s ( 0.00s) Task 1 (worker) : 0.58s ( 0.59s) 0.00s ( 0.01s) Task 2 (bound) : 0.58s ( 0.59s) 0.00s ( 0.00s) Task 3 (worker) : 0.00s ( 0.59s) 0.00s ( 0.00s) SPARKS: 1 (1 converted, 0 pruned) INIT time 0.00s ( 0.00s elapsed) MUT time 1.15s ( 0.59s elapsed) GC time 0.00s ( 0.01s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 1.15s ( 0.61s elapsed) %GC time 0.0% (2.4% elapsed) Alloc rate 1,391,432,695 bytes per MUT second Productivity 100.0% of total user, 190.3% of total elapsed gc_alloc_block_sync: 90 whitehole_spin: 0 gen[0].sync_large_objects: 0 gen[1].sync_large_objects: 0

6 7

Associative prefix operators in Parsec
by Troels Henriksen 12 Mar '12

12 Mar '12

Consider a simple language of logical expressions: > import Control.Applicative > import Text.Parsec hiding ((<|>), many) > import Text.Parsec.String > import Text.Parsec.Expr > > data Expr = Truth > | Falsity > | And Expr Expr > | Or Expr Expr > | Not Expr > deriving (Show, Eq) I define a simple expression parser using Parsec: > expr :: Parser Expr > expr = buildExpressionParser table (lexeme term) > <?> "expression" > > term :: Parser Expr > term = between (lexeme (char '(')) (lexeme (char ')')) expr > <|> bool > <?> "simple expression" > > bool :: Parser Expr > bool = lexeme (string "true" *> pure Truth) > <|> lexeme (string "false" *> pure Falsity) > > lexeme :: Parser a -> Parser a > lexeme p = p <* spaces > > table = [ [prefix "!" Not ] > , [binary "&" And AssocLeft ] > , [binary "|" Or AssocLeft ] > ] > > binary name fun assoc = Infix (do{ lexeme (string name); return fun }) assoc > prefix name fun = Prefix (do{ lexeme (string name); return fun }) Now this doesn't work: > test1 = parseTest expr "!!true" But this does: > test2 = parseTest expr "!(!true)" I have studied the code for buildExpressionParser, and I know why this happens (prefix operators are treated as nonassociative), but it seems like one would often want right-associative prefix operators (so test1 would work). Is there a common workaround or solution for this problem? I assume the nonassociativity in Parsec is by design and not a bug. -- \ Troels /\ Henriksen

2 3