January 2007 - Haskell-Cafe

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

Levels of recursion
by Andrew Wagner 02 Feb '07

02 Feb '07

I won't speak for anyone else, but I remember when recursion first "clicked". It was in a 400-level data structures and algorithms class. I had already done a fair amount of chess programming (which of course does a massive amount of recursion), but it still seemed a bit magical to me. When the professor pointed out that you simply have to assume that the recursive call will work, and then the whole recursive definition will, a light bulb went on. Of course, once I started learning haskell, such "aha!" moments quickly became a way of life. Things like map, foldr, and the lazy definition of fibs all made me stop and think for a while, and when I understood them, I was better for it. I had a sort of interesting moment like this last night. In hacking on some code, I wrote the following function: combine :: [Int] -> [Int] -> [[Int]] combine [] _ = [] combine (x:xs) ys = (take x ys) : (combine xs (drop x ys)) To me, this is recursion. Define your base case, take care of one part of the problem, and then call yourself recursively to take care of the rest. This is how I was taught recursion, and this is how I think about it. Now for the fun part. A much more experienced haskeller told me he preferred to write it like this: combine' :: [Int] -> [Int] -> [[Int]] combine' xs ys = snd $ mapAccumL aux ys xs where aux ys n = (b,a) where (a,b) = splitAt n ys Ack! Where'd the nice "base-case, take a chunk, recursively do the rest" pattern go? Suddenly, recursion isn't so simple when it's done using composition and higher-order functions which abstract recursive patterns. Like I said, I'm familiar with map, foldr, etc. But this is the first time it's dawned on me that I need to think in more general recursive patterns like this instead of simple, raw recursion. That map and foldr aren't JUST a nice way of doing things to a little list, but they are recursive operators, building blocks that I need to use as fluently as anything else. I suspect I'm not alone, though of course I could be wrong. But I would bet that a significant difference between newbies and more experienced Haskell programmers is the degree to which they can think in this composition/HOF way. Where the beginner wants to program using raw, simple recursion, the more experienced sees an opportunity to apply an abstraction. So, a couple of questions to ponder about this: Is this unique to Haskell, or could the same be said about any functional language? How can we teach this better to newbies? Most of what I see in the tutorials is "Higher order functions accept as parameters and/or return other functions. Here's some examples: <explanation of map>, <explanation of foldr>. Moving on, ..." But clearly, this is something important, and I think we can do a better job of teaching it. Suggestions?

4 3

Channel9 Interview: Software Composability and the Future of Languages
by Neil Bartlett 02 Feb '07

02 Feb '07

No doubt many of you will have seen the interview[1] on Channel9 with Anders Hejlsberg, Herb Sutter, Erik Meijer and Brian Beckman. These are some of Microsoft's top language gurus, and they discuss the future evolution of programming languages. In particular they identify composability, concurrency and FP as being important trends. However their focus is on borrowing features of FP and bringing them into mainstream imperative languages; principally C#. Naturally the subject of Haskell comes up repeatedly throughout the interview. Disappointingly they characterize Haskell as being an impractical language, only useful for research. Erik Meijer at one point states that programming in Haskell is too hard and compares it to assembly programming! Yet the interviewees continually opine on the difficulty of creating higher level abstractions when you can never be sure that a particular block of imperative code is free of side effects. If there were ever a case of the answer staring somebody in the face... I found this interview fascinating but also exasperating. It's a real shame that no reference was made to STM in Haskell. I don't know why the interviewer doesn't even refer to the earlier Channel9 interview with Simon Peyton Jones and Tim Harris - it appears to be the same interviewer. Still, it's nice to see that ideas from Haskell specifically and FP generally are gaining more and more ground in the mainstream programming world. It also highlights some of the misconceptions that still exist and need to be challenged, e.g. the idea that Haskell is too hard or is impractical for real work. [1] http://channel9.msdn.com/Showpost.aspx?postid=273697

10 22

ANNOUNCE: The Monad.Reader - Issue 6
by Wouter Swierstra 01 Feb '07

01 Feb '07

Dear all, I pleased to announce that the latest issue of The Monad.Reader is now available: http://www.haskell.org/haskellwiki/The_Monad.Reader Issue 6 consists of the following three articles: * Bernie Pope - Getting a Fix from the Right Fold * Dan Piponi - Adventures in Classical-Land * Russell O'Connor - Assembly: Circular Programming with Recursive do The Monad.Reader is a quarterly magazine about all things Haskell. It is less-formal than journal, but somehow more enduring than a wiki- page or blog post. If you'd like to submit something to the next issue of The Monad.Reader, please get in touch. The preliminary deadline for Issue 7 is March 30, 2007. I will send out an official call for copy in the coming weeks. For now, enjoy Issue 6! Wouter This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

8 9

Takusen - error handling and DBM monad
by Paul Moore 01 Feb '07

01 Feb '07

I'm continuing (in my occasional spare time) to try to write a "simple database query" in takusen. The query is OK now, but I'm struggling with error handling. I have a simple error handler catcher :: DBException -> DBM mark Session () catcher x = do liftIO $ putStrLn $ show x All it does is print the exception. The DBM mark Session () type, I deduced by fiddling until something works. Now, I can protect my query with something like main = do withSession (connect "..." "..." "...") ( do catchDB (do -- simple query, returning reversed list of rows. r <- doQuery (sql "select username from all_users") query1Iteratee [] liftIO $ putStrLn $ show r ) catcher ) So far, so good. The syntax is messy, but a little refactoring should fix that. But this doesn't catch errors in the connect call. Wrapping the withSession in catchDB doesn't work, as withSession is in the IO monad [1], not the DBM one. But using catch with catcher doesn't work, as that expects an error handler in the IO monad, but catcher is in the DBM monad. I'm getting very confused about the relationship between the DBM stuff and the IO monad. I'm sure there are good reasons for the DBM monad, but at the moment I'm missing them, and all I'm doing is trying random things, to little avail. If someone could give me a better understanding of the reasoning behind the DBM stuff, plus some pointers on how I should be interleaving IO and DBM stuff, I'd be hugely grateful. Apologies if this post is vague and/or badly expressed, but I'm currently a bit short of time, and fairly frustrated over what I feel should be a simple task (that imperative vs functional mismatch, again :-)) Thanks, Paul. [1] Excuse sloppy terminology here!

3 4

Think of a monad...
by Eric Y. Kow 01 Feb '07

01 Feb '07

Dear Haskellers, In the recent HWN, I noticed a new monad metaphor by Don Stewart: Think of a monad as a spacesuite full of nuclear waste in the ocean next to a container of apples. now, you can't put oranges in the space suite or the nucelar waste falls in the ocean, *but* the apples are carried around anyway, and you just take what you need This metaphor very clearly captures the essence of monads. Perhaps it will be even more helpful if accompanied by a small illustration: http://koweycode.blogspot.com/2007/01/think-of-monad.html I hope this turns out to be useful to somebody, -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français.

4 3

Re: [Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages
by Steve Schafer 01 Feb '07

01 Feb '07

On Fri, 26 Jan 2007 17:13:43 -0000 (GMT), you wrote: >world. It also highlights some of the misconceptions that still exist and >need to be challenged, e.g. the idea that Haskell is too hard or is >impractical for real work. Haskell _is_ hard, although I don't think it's _too_ hard, or I wouldn't be here, obviously. Haskell is hard in the sense that in order to take advantage of its ability to better solve your problems, you have to THINK about your problems a lot more. Most people don't want to do that; they want the quick fix served up on a platter. And even the "intermediate" camp, the ones who are willing to invest some effort to learn a better way, are only willing to go so far. My analogy for this is the Sams PHOTOFACT series (If you're not old enough to already know what these are, visit http://www.samswebsite.com/photofacts.html) With an appropriate Sams PHOTOFACT in hand, and some very basic skills with a voltmeter and maybe an oscilloscope, you can diagnose and repair your TV with virtually no understanding of electronics at all. The audience for programming languages like Haskell is always going to be small, because it appeals to those who want to understand how the TV works, perhaps to the extent of being able to modify an existing TV or even design one from scratch. And those kind of people are much fewer and farther between than those who simply want to localize the problem enough to be able to unplug the malfunctioning part and plug in a new one. It makes sense to publicize Haskell; you can't take advantage of something you've never heard of. But I think evangelical effort is largely wasted. The people who are going to gravitate towards Haskell are the ones who are already searching for something better (they just aren't sure what it is). The rest aren't really interested, and if at some future point they become interested, they'll find the way on their own. Steve Schafer Fenestra Technologies Corp. http:/www.fenestra.com/

30 65

ANNOUNCE: binary: high performance, pure binary serialisation
by dons＠cse.unsw.edu.au 01 Feb '07

01 Feb '07

Binary: high performance, pure binary serialisation for Haskell ---------------------------------------------------------------------- The Binary Strike Team is pleased to announce the release of a new, pure, efficient binary serialisation library for Haskell, now available from Hackage: tarball: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary/0.2 darcs: darcs get http://darcs.haskell.org/binary haddocks: http://www.cse.unsw.edu.au/~dons/binary/Data-Binary.html The 'binary' package provides efficient serialisation of Haskell values to and from lazy ByteStrings. ByteStrings constructed this way may then be written to disk, written to the network, or further processed (e.g. stored in memory directly, or compressed in memory with zlib or bzlib). Encoding and decoding are achieved by the functions: encode :: Binary a => a -> ByteString decode :: Binary a => ByteString -> a which mirror the read/show functions. Convenience functions for serialising to disk are also provided: encodeFile :: Binary a => FilePath -> a -> IO () decodeFile :: Binary a => FilePath -> IO a To serialise your Haskell data, all you need do is write an instance of Binary for your type. For example, suppose in an interpreter we had the data type: import Data.Binary import Control.Monad data Exp = IntE Int | OpE String Exp Exp We can serialise this to bytestring form with the following instance: instance Binary Exp where put (IntE i) = putWord8 0 >> put i put (OpE s e1 e2) = putWord8 1 >> put s >> put e1 >> put e2 get = do tag <- getWord8 case tag of 0 -> liftM IntE get 1 -> liftM3 OpE get get get The binary library has been heavily tuned for performance, particularly for writing speed. Throughput of up to 160M/s has been achieved in practice, and in general speed is on par or better than NewBinary, with the advantage of a pure interface. Efforts are underway to improve performance still further. Plans are also taking shape for a parser combinator library on top of binary, for bit parsing and foreign structure parsing (e.g. network protocols). Several projects are using binary already for serialisation: lambdabot : state file serialisation hmp3 : mp3 file database hpaste.org : pastes are stored in memory as compressed bytestrings, and serialised to disk on MACID checkpoints Binary was developed by a team of 8 during the Haskell Hackathon, Hac 07, and received 200+ commits over that period. You can see the commit graph here: http://www.cse.unsw.edu.au/~dons/images/commits/community/binary-commits.png The use of QuickCheck was critical to the rapid, safe development of the library. The API was developed in conjunction with the QuickCheck properties that checked the API for sanity. We were thus able to improve performance while maintaining stability. We feel that QuickCheck should be an integral part of the development strategy for all new Haskell libraries. Don't write code without it! Binary is portable, using the foreign function interface and cpp, and is tested with Hugs and GHC. Happy hacking! The Binary Strike Team, Lennart Kolmodin Duncan Coutts Don Stewart Spencer Janssen David Himmelstrup Bjorn Bringert Ross Paterson Einar Karttunen

19 50

DevRandom
by Yitzchak Gale 01 Feb '07

01 Feb '07

Have I re-invented the wheel yet again? I have a module the following simple functions, that I have been using for some time: -- Read data from the system random device. -- Return Nothing if there is currently not -- enough entropy in the system random device. devRandom :: Storable a => IO (Maybe a) -- Read data from the system random device. -- If necessary, wait until there is -- enough entropy in the system random device. devRandomWait :: Storable a => IO a -- Read data from the system random device. -- If there is currently not enough entropy -- in the system random device, use a lower -- quality source of randomness instead. devURandom :: Storable a => IO a These are currently implemented only for platforms that have a /dev/random and /dev/urandom device, i.e., Unix-like. I know how to implement the third function - devURandom - on Windows, but I don't currently have a Windows box on which I can compile Haskell. I don't know how to implement the other two functions on Windows. This seems like something that is important to be in the standard library, or at least publicly accessible. Is it out there already and I am just missing it? If not, what is the best way to make this available? Is there someone who would like to do the Windows part? -Yitz

2 5

Is Excel the most used -- and fucntional -- programming lanuage on Earth?
by Alexy Khrabrov 31 Jan '07

31 Jan '07

Heard that statement recently -- that Excel is a functional programming language, and the most used one -- of any programming languages -- on Earth! Is it true? Are there good examples of typical FP style in Excel? Cheers, Alexy

10 11