- Haskell-Cafe - Haskell.org

Ann: Win32-notify 0.1
by Niklas Broberg 05 May '08

05 May '08

Hi all, I wanted to use hinotify, which gives notifications on file system changes, but found (quite naturally) that it wouldn't run on my windows machine (since it's a binding to the linux kernel). So I started writing a library that would give similar functionality on Windows. This is the first release of that, more a proof-of-concept than anything useful at this stage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Win32-notify-0.1 Still, feel free to test it, and I would love feedback on everything from desired API to suggestions on how to implement the low-level bindings more efficiently. Cheers, /Niklas

6 6

sound synthesis
by Thomas Girod 05 May '08

05 May '08

Hi there. Following this advice (http://reddit.com/info/6hknz/comments/c03vdc7) I'm posting here. Recently, I read a few articles about Haskell (and FP in general) and music/sound. I remember an article ranting about how lazy evaluation would be great to do signal processing, but it was lacking real world example. I tried to do a little something about it, even though I'm still an haskell apprentice. So, here I come with a small bit of code, waiting for your insights to improve it. The task is to generate a sine wave and pipe it to /dev/dsp on my linux box. There is probably a nicer way to make some noise, like using SDL audio API bindings, but I didn't take the time to poke around this yet. So here it is : > module Main where > import qualified Data.ByteString as B > import Data.Word > import IO (stdout) > rate = 44100 > sinusFloat :: [Float] > sinusFloat = map (\t -> (1 + sin (t*880*2*pi/rate)) / 2) [0..44099] > sinusWord :: [Word8] > sinusWord = map (\s -> floor (s * max)) sinusFloat > where max = 255 > byte = B.pack sinusWord > main = B.hPut stdout byte It is supposed to generate a 880hz sine wav playing for one second, by typing ./bin > /dev/dsp, assuming your soundcard has a 44100hz samplingrate. /dev/dsp is supposed to receive its audio flux as an unsigned byte stream, that's why I'm converting my sine from [-1;1] to [0;1] and then to [0;255] Word8. However, I must miss something because the sound does not have the right frequency and is played too long. I guess the default sound format is 44100hz 16bits stereo, which would explain why it doesn't behave as expected. I'm wondering how I could convert a [Word16] to ByteString, and how I could use lazy evaluation to generate an infinite sine that stops with the interupt. Thomas

6 5

Re: Understanding tail recursion and trees
by Edsko de Vries 03 May '08

03 May '08

Hi, Thanks to Miguel for pointing out my silly error. So at least my understanding of tail recursion is correct :) So then the question becomes: what *is* the best way to write this function? One version I can think of is > ecount :: [Tree] -> Integer -> Integer > ecount [] acc = acc > ecount (Leaf _ : ts) acc = ecount ts $! (acc + 1) > ecount (Branch t1 t2 : ts) acc = ecount (t1 : t2 : ts) acc which essentially maintains an explicit stack and runs on all trees. Are there better ways to do this? Thanks again and sorry for my mistake, Edsko

5 7

castIOUArray and hPutArray redux
by Ben 03 May '08

03 May '08

hi haskellers, have the issues with castIOUArray (and thus hGetArray, hPutArray) in Data.Array.IO discussed below been resolved? http://www.haskell.org/pipermail/libraries/2003-January/thread.html here is a (trivial) program which has rather unexpected behavior. (i'm switching to Data.Binary in the meantime.) import Data.Array.IO import System.IO (IOMode(..), openBinaryFile, hClose) dumpArray arr name = do h <- openBinaryFile name WriteMode w <- castIOUArray arr (l,u) <- getBounds w let len = u-1+1 hPutArray h w len hClose h return len loadArray name num = do arr <- newArray_ (1, num) h <- openBinaryFile name ReadMode read <- hGetArray h arr num if not(read == num) then error "Incorrect number of bytes read in from array!" else return arr len = 20 main = do arr <- newArray (1, len) 1::IO(IOUArray Int Int) size <- dumpArray arr "foo" arr2' <- loadArray "foo" size arr2 <- (castIOUArray arr2')::IO(IOUArray Int Int) e1 <- getElems arr e2 <- getElems arr2 print e1 print e2 print size print $ show (arr == arr2) best, b

3 3

Understanding tail recursion and trees
by Edsko de Vries 02 May '08

02 May '08

Hi, I am writing a simple compiler for a small DSL embedded in Haskell, and am struggling to identify and remove the source of a stack error when compiling larger examples. To understand the issues better, I was playing around with tail recursion on trees when I came across the following problem. Suppose we want to count the number of leaves in a tree. The obvious naive (non tail-recursive) will run out of stack space quickly on larger trees. To test this, I defined a function that generates left (gentreeL, code below) or right (gentreeR) biased trees, that look like * * / \ / \ * * * * / \ / \ * * * * . . . . n n respectively; that is, a tree of depth n, with on the right (or the left) leaves only). Now, we can define define two traversals: one that has a tail call for the left subtree, after having traversed the right (acountL, below); and one that has a tail call for the right subtree, after having traversed the left (acountR). I was expecting acountL to work on the left biased tree but not on the right biased tree -- and that assumption turned out to be correct. However, I was also expecting (by "duality" :) acountR to work on the right biased tree, but not on the left biased tree, whereas in fact it works on both! (Indeed, it works on reallybigtree3, which combines the left and right biased trees, as well.) Can anyone explain why this is happening? Why is acountR not running out of stack space on the left biased tree? Also, if this is quirk rather than something I can rely on, is there a way to write a function that can count the number of leaves in reallybigtree3 without running out of stack space? Thanks (code follows), Edsko > data Tree = Leaf Integer | Branch Tree Tree > -- naive count > ncount :: Tree -> Integer > ncount (Leaf _) = 1 > ncount (Branch t1 t2) = ncount t1 + ncount t2 > -- generate left-biased tree (right nodes are always single leaves) > gentreeL :: Integer -> Tree > gentreeL 0 = Leaf 0 > gentreeL n = Branch (gentreeL (n-1)) (Leaf 0) > > -- generate right-based tree (left nodes are always single leaves) > gentreeR :: Integer -> Tree > gentreeR 0 = Leaf 0 > gentreeR n = Branch (Leaf 0) (gentreeR (n-1)) > > -- test examples > reallybigtree1 = gentreeL 2000000 > reallybigtree2 = gentreeR 2000000 > reallybigtree3 = Branch (gentreeL 2000000) (gentreeR 2000000) > > -- count with tail calls for the left subtree > acountL :: Tree -> Integer -> Integer > acountL (Leaf _) acc = acc + 1 > acountL (Branch t1 t2) acc = acountL t1 $! (acountL t2 acc) > > -- count with tail calls for the right subtree > acountR :: Tree -> Integer -> Integer > acountR (Leaf _) acc = acc + 1 > acountR (Branch t1 t2) acc = acountR t2 $! (acountL t1 acc)

3 2

Re: Function Type Calculation (Take 2)
by PR Stanley 02 May '08

02 May '08

Just in case anyone missed this: [1] funk f x = f (funk f) x f :: a x :: b funk f x :: c therefore funk :: a -> b -> c RHS f (funk f) x :: c f (funk f) :: d -> c x :: d f :: e -> d -> c funk :: h -> e f :: h unification f :: a = h = (e -> d -> c) x b = d No. x :: b = d (a typo?) Paul: What's wrong with x being of type b and of type d? Could you perhaps explain the error please? Don't forget also that funk :: a -> b -> c = h -> e, which means that e = b -> c Paul: is that something to do with partial application? (funk f) is a partially applied function, correct? Again an explanation would be appreciated. therefore funk :: ((h -> e) -> b -> c) -> b -> c No. I don't understand where you've got this expression from. It's funk :: a -> b -> c = (e -> d -> c) -> b -> c = ((b -> c) -> b -> c) - > b -> c According to GHCi: Prelude> let funk f x = f (funk f) x Prelude> :t funk funk :: ((t1 -> t) -> t1 -> t) -> t1 -> t which is about the same. Thanks Paul

2 1

elementary Maybe Monad problem .. sigh
by Galchin, Vasili 02 May '08

02 May '08

data Bozo = Bozo { id :: Int } bonzo :: Maybe Bozo -> IO () bonzo maybe_bozo = do if maybe_bozo == (Just (Bozo x)) then return () else return () ~ I want "x" to be a pattern that matches "id" .... ?? Kind regards, Vasili

5 6

Writing an 'expect'-like program with runInteractiveCommand
by Graham Fawcett 02 May '08

02 May '08

Hi folks, I would like to communicate with an external, line-oriented process, which takes a sequence of one-line commands, each returning an arbitrary number of lines, and waits for another command after each response. So, something like: sendCmd :: (Handle, Handle) -> String -> IO [String] ... main = do handles <- connectToExternalProcess sendCmd handles "do something" resp <- sendCmd "get results" -- needs strict I/O, before "quit"? sendCmd "quit" mapM_ putStrLn resp I've tried using runInteractiveCommand, and several combinations of hFlush, hWaitForInput, etc., but I can't find a combination that actually works. I know this is a sketchy description, but can anyone offer some sample code, or point me toward a program that has similar behaviour? Thanks, Graham

3 3

Test.QuickCheck.Gen
by Tony Morris 01 May '08

01 May '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am trying to understand the QuickCheck source in a bit of depth and I have noted that a Gen x is a function Int -> StdGen -> x, however, some of the combinators can at times, fail to ever produce a result by throwing an error. I include an example using ghci: *Test.QuickCheck> (f 0 (mkStdGen 0)) :: Int *** Exception: Prelude.(!!): negative index It seems this can be alleviated by changing Gen x to Int -> StdGen -> Maybe x and having the generator produce Nothing when a combinator fails. However, now the function promote cannot be written (I have tried and run into the conundrum of writing the function (a -> Maybe b) -> Maybe (a -> b)), which is used to generate functions. So, I'm caught on the fence about whether there is a possible improvement here (for example, should the elements function throw the error?), or if the current scenario is acceptable. I'm seeking comments about this, thanks! - -- Tony Morris http://tmorris.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIGjO6mnpgrYe6r60RAtohAKCBsl1lHxuNrBaLHuqwCN58PBHCIACbBALk YWkBkw9o9NUQbr+lgo0rXE0= =JQlH -----END PGP SIGNATURE-----

1 0

ANN: Haddock version 2.1.0
by David Waern 01 May '08

01 May '08

Hi everyone, I'm pleased to announce Haddock 2.1.0. Hackage page: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haddock-2.1.0 Changes since last version: * Fix a bug that made links point to the defining module instead of the "best" one (e.g Int pointing to GHC.Base instead of Data.Int) * Fix a couple of smaller bugs * The representation of DocName was changed in the library * Add a flag --no-warnings for turning off warnings David

2 2