February 2010 - Beginners

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