February 2007 - Haskell-Cafe

learning Haskell
by Bulat Ziganshin 09 Feb '07

09 Feb '07

Hello, i'd a discussion in russian programmer's forum (rsdn.ru) about haskell and learning it. one interesting point was that imperative programmers imagine that multi-threading programming should require special knowledges. they was really amazed when i showed the following program that creates thread and interacts with it - without locks, semaphores, synchronized access and all other old stuff -- Thread, that cyclically read commands from channel, and executes them graphThread c = do cmd <- getChan c cmd graphThread c -- Creates graphThread and sends a few commands to it for execution main = do c <- newChan forkOS $ graphThread c putChan c (print "Hi") tid <- forkOS $ putChan c (print "Hi from other thread") putChan c (print "Bye") waitThread tid i think that some example like it would be appropriate in haskell book for *novices* - just because it's easy to do in Haskell. so, i vote for adding Multi-threading chapter to such books (and it may be especially important nowadays when everyone are crazy about multi-cores :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

weak references & caches
by Thomas Conway 08 Feb '07

08 Feb '07

Hi All, I'm hacking some (external) B-Tree code, and amongst the numerous interesting problems I've come up against[*], is to do with managing which pages/nodes are in memory and which are not. We use TVars to point from one (in-memory version of a) page to another, so we have a type like the following: data Node = Leaf [(Key,Value)] | Node NodePtr [(Key,NodePtr)] type NodePtr = TVar (Maybe Address, Maybe Node) type Address = Integer Addresses are just page numbers or file offsets, or similar. NodePtr is the interesting bit - the following table summarizes what the combination of values mean: explain (Just addr, Nothing) = "An external node we have not read in yet" explain (Nothing, Just node) = "A new node for which we have not yet allocated a page" explain (Just addr, Just node) = "A node we've read in" explain (Nothing, Nothing) = "Emit nasal daemons" Now, we want a cache to hang on to nodes that we've read in to hold them in memory, to save repeatedly reading them off disk unnecessarily. But more than that, we want to make sure that when we create a NodePtr pointing to a particular Address, that all references to this particular address go through the same NodePtr, otherwise in a concurrent situation we could well end up with two copies of the page in memory, both recieving updates leading to havoc. At the same time, we'd like to be able to evict pages according to some policy (the Oracle hot-list cold-list cache is attractive, if implemented carefully). So one scheme that comes to mind is to keep a table mapping addresses to (Weak NodePtr). When we ask for a node, first we consult the cache (if we have one) and get the NodePtr right back. If the addressed node is not in the cache then we check the table to see if there is/was a known NodePtr for that address. If there is none then we can allocate a new one and stick it in the table, and if it is there then we return it. This is also nice because we can attach finalizers to the (Weak NodePtr)s to write them out if dirty. So the question is, is there a simpler scheme (though this one isn't tooooo bad), and more importantly, is this likely to be horribly slow? How efficient is dereferencing a weak reference, and what is the likely impact on performance of having 10^3-10^5 weak references around? cheers, Tom [*]Film at 11. I'm planning to write it all up, maybe for a conference, maybe just for the Monad Reader, or something.

1 1

Portable implementation of unsafeCoerce
by Alfonso Acosta 08 Feb '07

08 Feb '07

Hi all, Reading the sources of Lava (a Haskell Hardware Description DSL) I run into this definition ... unsafeCoerce :: a -> b unsafeCoerce a = unsafePerformIO $ do writeIORef ref a readIORef ref where ref = unsafePerformIO $ do newIORef undefined Is this actually equivalent to the infamous unsafeCoerce# ? Thanks in advance, Alfonso Acosta

3 2

Monolithic module tool
by Chad Scherrer 08 Feb '07

08 Feb '07

Maybe a year or so ago, I came across a tool for Haskell that takes a collection of modules, does some name-mangling, and gives a single module that only needs to export main. There were wonderful reductions in the size of the resulting executable, and potentially more optimizations available to GHC. Anyway, I can't find the link now, and I'm wondering if anyone knows of it. Thanks! Chad

2 1

still wrestling with io
by Martin DeMello 08 Feb '07

08 Feb '07

Code here: http://zem.novylen.net/anagrid.html I've got an instance of IO appearing unexpectedly and I can't figure out where from. It throws up the following error: $ ghc --make test.hs Chasing modules from: test.hs Compiling Main ( test.hs, test.o ) test.hs:38:15: Couldn't match `StaticText ()' against `IO (StaticText ())' Expected type: StaticText () Inferred type: IO (StaticText ()) In the application `staticText p [text := (labelText a b)]' In the definition of `textOf': textOf p a b = staticText p [text := (labelText a b)] martin

3 2

How did you stumble on Haskell?
by Alexy Khrabrov 08 Feb '07

08 Feb '07

How do people stumble on Haskell? I've taught ML at UPenn, and many of my colleagues in Amazon are in SeaFunc -- switching from C funk to func funk. I've got Hudak's book a while ago, but didn't have time/excuse to delve into it until recently. Then the most fantastic chain if events triggered it: -- finally switched to Intel Mac -- got Parallels -- got a recent Linux, openSUSE 10.2, to stick into Parallels -- decided finally to try Gentoo -- found equery slow, came across Adelie/FQuery as "fast equery" -- emerge adelie To my surprise, saw it emerge GHC! Realized Adelie is a Haskell way to hack Portage. Dug all things Haskell! I also used Darcs for a long time. It probably takes several pro et contra factors to push away from boring things and to be inducted into interesting FP things. Again, UPenn focus on ML was invaluable, and Ullman's book on ML superb -- and thin! What's folks most interesting ways to arrive at FP? Cheers, Alexy

26 30

currying vs partial application
by Steve Downey 07 Feb '07

07 Feb '07

I think I finally have it. Partial application is taking a function of N parameters, binding a value to one of them, and turning it into a function of N-1 parameters. Currying is where ask is that a function that takes two ints and returns an int, or is that a function that takes one int and returns a function that takes an int and returns an int, and the answer is yes. Currying implies partial application, but not all partial application is currying.

1 0

Importance of MonadRandom
by Yitzchak Gale 07 Feb '07

07 Feb '07

I would like to point out the importance of Cale Gibbard's MonadRandom, beyond what is currently mentioned on its wiki page: http://www.haskell.org/haskellwiki/New_monads/MonadRandom This monad makes it possible to write functions that use randomness without having to specify in advance whether the source of randomness will be a pure pseudorandom number generator, as in System.Random, or physical randomness via the IO monad, such as your operating system's source of physical randomness, or random.org, or a hardware random generator. Before use of MonadRandom becomes widespread - and I think it ought to - I would like to suggest a change to the interface. (I mentioned this once to Cale on #haskell, but I didn't say what change I meant.) Currently, the members of the MonadRandom class mimic the members of the Random class in System.Random. I think it would be better if instead they mimicked the members of RandomGen. Like this: \begin{code} class (Monad m) => MonadRandom m where nextR :: m Int splitR :: m (m ()) rangeR :: m (Int, Int) getR :: (forall g . RandomGen g => g -> a) -> m a \end{code} The extra function getR provides access not only to the member functions of Random, but to any function that generates random variables of any type. You would use getR random, getR $ randomR (a, b), etc. instead of getRandom, getRandomR (a, b), etc. Provide a default method for getR as follows: \begin{code} getR f = do r <- nextR (lo, hi) <- rangeR return $ f $ TrivialGen r lo hi data TrivialGen = TrivialGen Int Int Int instance RandomGen TrivialGen where next (TrivialGen r _ _) = r genRange (TrivialGen _ lo hi) = (lo, hi) split _ = undefined \end{code} We would use the default method of getR for MonadRandom instances of things like DevRandom, DevURandom, RandomDotOrg, etc. For the Rand and RandT instances we provide explicit methods: \begin{code} -- For RandT: getR f = RandT $ gets f --For Rand: getR =Rand $ getR f \end{code} I think this is better for several reasons: o We anyway need getR for general random variables o We could lose precision getting other random variables via getRandom in the case where genRange /= (minBound, maxBound) o I think it is a better semantic fit Regards, Yitz

2 3

nested maybes
by Martin DeMello 07 Feb '07

07 Feb '07

I have a Data.Map.Map String -> (Layout, [String]) as follows: type Anagrams = [String] type Cell = (Layout, Anagrams) type WordMap = Map.Map String Cell exists str wmap = let a = Map.lookup (sort str) wmap in case a of Nothing -> False Just x -> case (find (== str) (snd x)) of Nothing -> False _ -> True the existence test looks ugly - any more compact way to write it? martin

15 29

haskell and releasing resources
by Fawzi Mohamed 07 Feb '07

07 Feb '07

I am just coming to haskell, and I wrote a simple command to get some input from a pdf file I just wanted the output of the command so I did something like import System.Process (runInteractiveCommand) import IO (hGetContents) -- | returns the text of the first page of the pdf at the given path, needs pdftotext getTextOfPdf :: String -> IO String getTextOfPdf pdfPath = do (inp,out,err,pid) <- runInteractiveCommand ("pdftotext -l 1 "+ +pdfPath++" -") return (hGetContents out) I don't care about error handling, if something goes wrong it is ok to hang or crash, but knowing unix I wondered if this would do the right thing or if it would create a zombi process. I was about to ask, but then I thought "let's test it", and sure enough the zombi stays there. I tried to even to allocate more than one, wait, I even managed to exhaust the resources of my machine... So here is what I would have liked to happen: when the pid gets garbage collected it tries to wait for the process, and if that fails the pid stays around longer and will try to wait later. Too difficult? I don't know, but it is what I had expected from haskell. Failing that I would have expected clear hints that one should wait for external processes in the documentation, and I found none. So what is the way out? I could do a forkIO and wait for the process but then I wonder do I have to wait for the thread, or dead thread become zombi? I that is the case then the only way out would be to give back also the pid and make the waiting responsibility of the caller, not very nice, but probably the real solution. I have seen that in missingh there is a pipeout example but it seems to me that you are still responsible to wait for the process (with ensureSuccess). Maybe the correct thing is not being able to ignore the return code of the process.... but now I am becoming suspicious of other things, for example a file handle, you need to close it or you can expect that it will be closed when the handle is garbage collected? Are there other places where you need to pay attention to be sure that you are releasing the resources you acquired? I suppose problems can come only when an external resource is involved, or not So 1) documentation should specify if one should do some specific action to free resources, can someone fix this? 2) is there a clean (haskell;) way to deal with this? 3) other places apart external processes where you have to pay attention? What is your wisdom... thanks Fawzi

5 12