- Haskell-Cafe - Haskell.org

ANN: Takusen 0.6
by Alistair Bayley 02 Feb '07

02 Feb '07

We are pleased to announce a new release of Takusen. There are a large number of changes and bug-fixes: - Oracle support for processing cursors returned from procedure calls - withContinuedSession supports connection reuse (e.g. for persistent connections and connection pooling) - new README file with useful information about getting started with Takusen - new UTF8 en/de-coder (the old one was buggy) - PostgreSQL support for CalendarTime - improved Cabal Setup.hs script, which does a better job of modifying the installation to reflect installed DBMS's. This gives good ghci support (PostgreSQL users on Windows have a small extra step) - prepared statement API requires that users distinguish between queries and DML Our long-term plans are the same as ever: - large objects - ODBC and MS Sql Server backends Release: http://darcs.haskell.org/takusen/takusen-0.6.tar.gz Source: darcs get --partial http://darcs.haskell.org/takusen Oleg and Alistair

1 0

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 02 Feb '07

02 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