February 2007 - Haskell-Cafe

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

Re: [Haskell-cafe] Channel9 Interview: Software Composability and the Future of Languages
by Steve Downey 01 Feb '07

01 Feb '07

The 70's and early 80's were very different in terms of information propagation. I really miss some the journals available back then, because the editors really did their jobs, both in selecting and helping to convey, information. OO did get oversold. The same way that putting it on the internet did at the beginning of this century (I love saying that, now, where's my flying car) but just like many of the good principles of structured programming inform OO, it should be possible to take good OO and apply it functionally. On 1/30/07, Bulat Ziganshin <bulat.ziganshin(a)gmail.com> wrote: > Hello Steve, > > Friday, January 26, 2007, 10:03:09 PM, you wrote: > > > Haskell _is_ hard, although I don't think it's _too_ hard, or I wouldn't > ... > > > 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, > > i don't think so :) imho, we just don't have good _teachers_. in > 70's, OOP audience was also small, but it was popularized later and > now every student know about polymorphism via inheritance. but most of > OOP programmers don't reinvent the wheels, they just use "patterns" > described in OOP bestselling books > > i have a positive experience of making "complex" concepts easy and > available for wide audience ([1]-[5]), [1] was even used to teach > students in some college. and i guess that good Haskell books, such as > yaht and printed ones, also make it easy to learn Haskell. but we need > to gather much more attention to Haskell to make it as "patternized" > as structured-programming and OOP. _nowadays_ there is no even one > "advanced Haskell" or "Haskell in Real World" book and this means that > anyone who want to learn Haskell in deep should study those terrible papers > > (well, it's very like higher education in Russia - no one really > teaches you at our colleges so you should either learn yourself or die :) > but this means that at least whose who still alive, are Real Machos :) > > the same apply to Haskell - now the only way to learn it is to learn > yourself, so we all definitely are cool mans. once i even got C# job > offer only because i know Haskell :) > > > [1] http://haskell.org/haskellwiki/IO_inside > http://haskell.org/haskellwiki/OOP_vs_type_classes > http://haskell.org/haskellwiki/Modern_array_libraries > http://haskell.org/bz/th3.htm > http://haskell.org/bz/thdoc.htm > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

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

"Circular" programming (aka time-travel) resources?
by Justin Bailey 01 Feb '07

01 Feb '07

In "The Monad.Reader - Issue 6", that just came out, there is a really interesting article that uses a "circular" technique to implement an assembly language in Haskell. The technique demonstrated seems fascinating. Can someone point me to more resources on the topic? A quick google search turned up a couple of blogs and some papers - but is there more out there? Thanks for any help! Justin

3 2

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

data package
by Pavel Rozenblioum 01 Feb '07

01 Feb '07

Hi, I am trying to compile the GLR examples from Happy 1.16, but I get the message that I am missing the "data" package. Where can I download it from? I am using GHC 6.6 /pavel

1 0

Modulo-foo equivalence classes in Haskell?
by Diego Navarro 01 Feb '07

01 Feb '07

Watching the questions go by in #haskell, a still fuzzy but possibly pregnant idea popped up in my mind. Someone needed a nubBy function that returned an unique list modulo an arbitrary function foo. Well, in this case it wasn't arbitrary; he had a list of transposable matrices and wanted an unique list of matrices that couldn't be transposed into each other. I'm thinking there are many cases of fooBy functions that have to be constantly rewritten, and also a lot of ugly code by having to constantly add the modulo clauses (like in modular arithmetic). I'm inexperienced with type classes -- I've only done the simplest types and /some/ fundeps -- so I'm wondering what would be the clearest, most general way of having a Modulo-foo Eq class that could be parameterized with a function. The "transposable matrix" example shows how this could be useful for (some limited form) of data compression, but it could make some other forms of "algebraically modular" (this is not a proper term, it's me trying to get thoughts across) business rules, of which modular arithmetic is a special case. Uh, I've probably not expressed myself well enough; I hope I have a shot at trying to explain myself better if questions come up. -- -- Diego Navarro

2 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