- Beginners - Haskell.org

Problems installing TagSoup.Parsec
by Mark Wong-VanHaren 02 Feb '10

02 Feb '10

Hi, folks- I'm a Haskell newbie. There's a very real chance my question has a simple answer. I wish to use the library Text.HTML.TagSoup.Parsec ( http://hackage.haskell.org/package/tagsoup-parsec) which looks very cool. When I attempt to install it, I get this error: # cabal install tagsoup-parsec Resolving dependencies... Configuring tagsoup-parsec-0.0.6... Preprocessing library tagsoup-parsec-0.0.6... Building tagsoup-parsec-0.0.6... [1 of 1] Compiling Text.HTML.TagSoup.Parsec ( Text/HTML/TagSoup/Parsec.hs, dist/build/Text/HTML/TagSoup/Parsec.o ) Text/HTML/TagSoup/Parsec.hs:37:5: `Tag' is not applied to enough type arguments Expected kind `*', but `Tag' has kind `* -> *' In the type synonym declaration for `WholeTag' cabal: Error: some packages failed to install: tagsoup-parsec-0.0.6 failed during the building phase. The exception was: exit: ExitFailure 1 It would seem to be a type mismatch between TagSoup.Parsec and the base TagSoup (on which it depends). Suspecting that the version-number dependency information might be incorrect, I tried uninstalling TagSoup and reinstalling an older version. This didn't help. Can anyone steer me in the right direction? Thanks! -Mark

2 3

hunit question
by Joe Van Dyk 02 Feb '10

02 Feb '10

I have a little binary search function and am trying to write tests for it in hunit. The below approach doesn't compile, because I'm attempting to build a list of tuples of different types, which isn't working for me. What's the appropriate way to do this test? http://gist.github.com/293031 import Test.HUnit import JoeBinarySearch -- Note: -- JoeBinarySearch.binary_search :: (Ord a) => [a] -> a -> Maybe Int assertions = [ ([1], 1, (Just 0)), ([1, 3], 1, (Just 0)), ([1, 3, 4], 4, (Just 2)), ([1,2,4,6,8,9,12,15,17,20], 17, (Just 8)), ([1,2,4,6,8,9,12,15,17,20], 20, (Just 9)), ("hello", 'l', (Just 2)), -- BOOM ([0.0, 1.5, 3.0], 3.0, (Just 2)), ([], 1, Nothing), ([1,3], 2, Nothing), ([1,4,6,8,9,12,15,17,20], 2, Nothing), ([1,4,6,8,9,12,15,17,20], 100, Nothing), ([1,4,6,8,9,12,15,17,20], (-100), Nothing)] test_list = TestList test_cases where test_cases = map test_func assertions test_func (lst, input, expected) = TestCase $ assert_equal' ( binary_search lst input ) expected assert_equal' = assertEqual "should equal" main :: IO () main = do runTestTT test_list print "DONE" -- Joe Van Dyk http://fixieconsulting.com

2 5

Using Debug.Trace
by legajid 02 Feb '10

02 Feb '10

Hi, Starting with trace, i have trouble with my calcul'' function while calcul' is ok. When afftrace in calcul'' is commented, the program compiles. When uncommented ( afftrace (" calcul'' vide") ), i get the following messages : ------------------------------------------------------------------------------------------- *Main> :r [1 of 1] Compiling Main ( sud3c.hs, interpreted ) sud3c.hs:62:3: Couldn't match expected type `[Char]' against inferred type `(Plateau, Char)' In a stmt of a 'do' expression: afftrace (" calcul'' vide") In the expression: do afftrace (" calcul'' vide") (pxv, False) In the definition of `calcul''': calcul'' pxv _ [] = do afftrace (" calcul'' vide") (pxv, False) Failed, modules loaded: none. ------------------------------------------------------------------------------------------- I don't understand why, in calcul', it's ok and why, in calcul'', it's problematic. Because return value of calcul'' is a tuple ? When my program is ok, should i remove all trace instructions (and associated do commands too) or just set my modetrace value to False ? Thanks for helping, Didier Below my code : calcul' :: Plateau -> [Cellule] -> Plateau calcul' pxv [] = do afftrace (" Calcul' vide") pxv calcul' pxv (c:cs)= do afftrace (" Calcul' ok1="++show ok1++" c:cs= "++show (c:cs)) afftrace (" "++show xv1) if ok1 then do afftrace (" Calcul' suite") calcul' xv1 cs else do afftrace (" Calcul' pas de valeur") pxv where vallib=[1..length pxv]++[5..7] nbvlib=length vallib (xv1,ok1)=calcul'' pxv c vallib calcul'' :: Plateau -> Cellule -> [Valeur] -> (Plateau, Bool) calcul'' pxv _ [] = do --afftrace (" calcul'' vide") (pxv, False) calcul'' pxv c (li : lis) = do --afftrace (" "++show pxv) --afftrace (" "++show c ++ " "++show(li:lis)) v2 where v2= if (elem li pxv || li==4) then calcul'' pxv c lis else do --afftrace (" calcul'''") (calcul''' pxv c li, True) calcul''' :: Plateau -> Cellule -> Valeur -> Plateau calcul''' pxv c li = take (c-1) pxv ++ [li] ++ drop c pxv afftrace x= if modetrace then trace x " " else " "

2 2

Performance of Idiomatic lazy Haskell
by Markus Böhm 02 Feb '10

02 Feb '10

As a beginner fascinated about Haskell's lazy, idiomatic style I tried a small example: Calculate a numerical approximation of PI based on the Leibniz formula. Variant 1: My lazy, idiomatic approach (as I understand it so far). It takes on my machine with eps = 0.00000001 approx. 25 sec. import Data.List main :: IO () main = do putStrLn "EPS: " eps <- readLn :: IO Double let pi14 = calcpi14 eps putStrLn $ "PI mit EPS "++(show eps)++" = "++ show(4*pi14) calcpi14:: Double->Double calcpi14 eps = foldl' (+) 0 $ takeWhile (\x -> 4 * abs x > eps) ev where e = map (\x->1.0/x) [1.0,3.0..] ev = zipWith (*) e $ cycle [1.0,-1.0] Variant 2: My "C-style" approach achieving state via additonal function parameters. It takes on my machine with eps = 0.00000001 approx. 5 sec. import Data.List main :: IO () main = do putStrLn "EPS: " eps <- readLn :: IO Double let pi14 = pisum 1 3 False eps putStrLn $ "PI mit EPS "++(show eps)++" = "++ show(4*pi14) pisum s i _ eps | 4/i < eps = s pisum s i True eps = let h = s + 1/i in h `seq` pisum h (i+2) False eps pisum s i False eps = let h = s - 1/i in h `seq` pisum h (i+2) True eps I'd like to do idiomatic, lazy Haskell w/o such a performance penalty? How can I learn/achive that? -- Markus

6 23

Re: foldl' vs seq
by Gabi 02 Feb '10

02 Feb '10

Thank you Ertugrul, I think I got it now. My lesson here is to avoid recursion as much possible and use foldr' instead.There are too many pitfalls. -- Regards, Gabi http://bugspy.net

2 1

foldl' vs seq
by Gabi 02 Feb '10

02 Feb '10

Hi Stephen, Thanks for the answer. Now I got confused :) 1. What is seq used for if it doesn't force strictness ? 2. Why the accumulator is important ? In other words why the following is much slower ? Isn't it RT too ? slowSum :: [Integer] -> Integer slowSum[] = 0 slowSum (x:xs) = x `seq` x + slowSum xs

3 3

Re: [Haskell-beginners] one more step backwards
by Felipe Lessa 01 Feb '10

01 Feb '10

On Mon, Feb 01, 2010 at 10:32:00PM +0000, John Moore wrote: > Hi Felipe, > this is way complicated for my level, could you look at this > below and see if I could use this instead. I understand you, it also took me some time to understand the monad transformer library :). > evalStep :: Expression -> Expression > evalStep (Val x)= (Val x) > evalStep (Add x y) > = case x of > (Val a) -> case y of > (Val b) -> Val (a+b) > left -> Add x (evalStep y) > right -> Add (evalStep x)y Even without the Writer monad you capture that pattern in an auxiliary function. You just extract the common bits and abstract the specific ones: aux calcOp mkOp x y = case x of (Val a) -> case y of (Val b) -> Val (a `calcOp` b) left -> mkOp x (evalStep y) right -> mkOp (evalStep x) y Note that: - I've changed (+) into calcOp and Add into mkOp. - Instead of deconstructing with a pattern match, I receive x and y as proper arguments. The type is type CalcOp = Integer -> Integer -> Integer type MkOp = Expression -> Expression -> Expression aux :: CalcOp -> MkOp -> Expression -> Expression -> (Expression -> Expression) You can write your evalStep as evalStep :: Expression -> Expression evalStep (Val x) = Val x evalStep (Add x y) = aux (+) Add x y evalStep (Subtract x y) = aux (-) Subtract x y evalStep (Multiply x y) = aux (*) Multiply x y evalStep (Divide x y) = aux div Divide x y Much cleaner ;). > What I mean to do is build up a history on a list and then take it of a > list( Same principle as a stack but a little more simple) the problem is how > do I get the other elements back of the list as in the line "r" -> evaluate > (I'm not sure what I put here) Hopes this makes some sort of sense. It does makes sense. In most languages this is the sort of code you would write: when the user tell us to evaluate, we evaluate and then save the result. However in our language we can leverage the laziness: buildHistory :: Expression -> [Expression] buildHistory expr = expr : buildHistory (evalStep) You may recognize this function as buildHistory = iterate evalStep (Note that unless your expression is infinite, then this list will contain an infinite number of duplicates when we reach the fixed point of the evalStep function.) The idea is to take everything you can out of IO. With buildHistory we take the logic of evaluating the expressions further out of IO. Now your function is as trivial as mine. In fact, it is the same. HTH, -- Felipe.

1 0

problem with hsc2hs
by Jose A. Ortega Ruiz 01 Feb '10

01 Feb '10

Hi, I'm trying to writing a simple C binding for statfs(2). Simplifying, writing an hsc file that contains the following snippet: #include <sys/vfs.h> data CStatfs foreign import ccall unsafe "sys/vfs.h statfs" c_statfs :: CString -> Ptr CStatfs -> IO CInt getFileSystemStats :: String -> IO CLong getFileSystemStats path = allocaBytes (#size struct statfs) $ \vfs -> useAsCString (pack path) $ \cpath -> do res <- c_statfs cpath vfs case res of -1 -> return 0 _ -> do bsize <- (#peek struct statfs, f_bsize) vfs bcount <- (#peek struct statfs, f_blocks) vfs bfree <- (#peek struct statfs, f_bfree) vfs bavail <- (#peek struct statfs, f_bavail) vfs -- Just for demonstration: the original code creates a data structure return $ bsize + bcount + bavail + bfree gives rise, when using hsc2hs, to this translation: getFileSystemStats path = allocaBytes ((84)) $ \vfs -> useAsCString (pack path) $ \cpath -> do res <- c_statfs cpath vfs case res of -1 -> return 0 _ -> do bsize <- ((\hsc_ptr -> peekByteOff hsc_ptr 4)) vfs bcount <- ((\hsc_ptr -> peekByteOff hsc_ptr 8)) vfs bfree <- ((\hsc_ptr -> peekByteOff hsc_ptr 16)) vfs bavail <- ((\hsc_ptr -> peekByteOff hsc_ptr 24)) vfs return $ bsize + bcount + bavail + bfree (where i have deleted LINE directives). The problem is that the size and some of the offsets of the C struct statfs computed by hsc2c are wrong: i'm in a 32bit linux system, and i've checked, using a C program, that sizeof(struct statfs) is 64 (hsc2 is giving 84 -- although perhaps Haskell needs additional space for housekeeping?), and that the offsets of f_bfree and f_bavail are, respectively, 12 and 16 (not 16 and 24). Also, i know that 12 and 16 are the right values because putting them by hand gives me the correct statfs values. (This is ghc 6.10.4 on a debian/sid system) What am i doing wrong? TIA! jao

1 0

foldl' vs seq
by Gabi 01 Feb '10

01 Feb '10

Hi I am trying to understand the behavior of foldl' and seq. Why is the following code is much slower than the foldl' version ? (which is foldl' (+) 0) I thought the the below code is equivalent to foldr' but apparently I was wrong. mySum :: [Integer] -> Integer mySum[] = 0 mySum (x:xs) = seq x (mySum xs + x)

2 1

foldl' vs seq
by Gabi 01 Feb '10

01 Feb '10

Update: I came up with the following somewhat faster function. But still, it is much slower than the original foldl' mySum2 (x:y:xs) = let sum = x + y in seq sum (sum + mySum2 xs) mySum2 (x:[]) = x mySum2 [] = 0

1 0