Hi, Take a look at http://www.haskell.org/haskellwiki/HGene which uses HSQL and Gtk2hs. I don't have any code to release yet - only parts work and the code is in an extreme state of flux; I am currently refactoring (see my post on monads). More generally you might be interested in the other page that I have started http://www.haskell.org/haskellwiki/Enterprise_Haskell Mark Duncan Coutts wrote:

On Sat, 2006-12-16 at 19:50 +0100, Waldemar Biernacki wrote:

...

Hello!

I'd like to start programming in Haskell. But as an "industry programmer" I have a hope to use Haskell in my every-day work. Big part of my every-day work are GUI applications (in MS-Windows) working with SQL databases (PostgreSQL on Linux servers).

My question: Is there a TRUE possibility to use Haskell for such applications? Is anybody there who have ANY experience in the field? If answer would be positive what GUI+database libraries could be used in such a case?

I don't actually know of anyone using one of the GUI libs in combination with one of the DB libs. It's an obvious thing to do but you'll not find a lot of pre-existing examples or infrastructure to help you.

That's certainly one of the use cases that we're aiming for in the Gtk2Hs project with our new api for the list/tree widget system. We can now more easily implement the data model in Haskell so the obvious thing to try would be a model based on a DB query. We're aiming for a Gtk2Hs release with this new api before xmas.

For databases there are three major libs you could use, HDBC, HSQL, and HaskellDB. HSQL and HDBC are in essentially the same niche, they provide a common medium level api to a bunch of different db backends. They work at the level of taking SQL strings and returning result sets. HaskellDB is a higher level library (that can use HDBC or HSQL). It provides a type safe way of constructing queries (and internally generates SQL).

So personally what I'd try would be Gtk2Hs+HDBC or Gtk2Hs+HDBC+HaskellDB.

...

I've seen some GUI libraries web pages, but they seem to be NOT maintenanced any more.

There are several GUI libs that were started but not maintained. The main ones that are maintained are Gtk2Hs and wxHaskell.

For platform support you're fine, all those DB libs support PostgreSQL and both GUI libs support Windows, Linux and others.

Duncan

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

That said, if I was writing a GUI+database thing, which doesn't do a lot of substantial processing (more just Add/Edit/Delete buttons), I'd definately use C# over Haskell. Haskell can do this, but you are walking a relatively new path. On the other hand C# developers do this day in, day out, and the language is optimised towards it.

I agree with Neil here. I've been working with Haskell for a while and I wouldn't have the foggiest idea of how to start a GUI / Database project. After working with C# for about a week, I had a substantial GUI / Database program going for a company I interned with last summer. Haskell is good for a lot of things, and I'm sure somebody someday will show me that Haskell is even great for GUI/Database, but you should always use the right tool for the job, and for your job, I'd say C# is the right tool. Bryan Burgers

Hi Waldemar,

The final aim of the aproach is to get a tool in which there will be no syntactic errors during modelling bussiness logic. Recently I've finished very primary version of the tool (0.001:-).

Ah, now that sounds like Haskell might be good for :) Haskell isn't great at writing a GUI and database combination, in my experience. It certainly can, it just tends to be a bit of work. Having said that, Haskell is _great_ for writing domain specific libraries, for plugging together new applications and for modelling business logic. It's likely that your business logic has some standard set of operations, which you combine in some way - this is the thing Haskell excels at - defining small things, and combining them in new ways. The type system will help to ensure that the combinations are good, which again helps reduce errors.

I do not know C#, but what was attracting me to Haskell is - as they say - compact, clean and very functional way of programming.

Yes, a well designed Haskell program will give much better separation of concerns. You can totally separate the logic from the user interface gunk, and it will be more maintainable.

Maybe, but what is still unclear for me: Haskell is wrong for GUI/Database application because of lack of good libraries or because of it's way of programming???

The libraries for GUI programming are not great - they are progressing, and can certainly be used to develop tools, but I don't feel they are "the good stuff" yet. Maybe I'm just setting the bar higher because the rest of Haskell is so nice. The current style of GUI programming in Haskell tends to be in the IO monad, and feel very much like imperative programming. Haskell is perfectly capable of being an imperative programming language where required, but its not as natural as something like C# in this respect. So in answer to your question, I'd say a little of both, but with the optimistic view that one day someone will figure out what a GUI program in Haskell should look like and everyone wlil be happy :) Thanks Neil

sum <- newIORef 0

i <- newIORef 1 let go = do i' <- readIORef i when (i'

why in the world would you write a summation function like that?

Bulat Ziganshin wrote:

Hello Waldemar,

Sunday, December 17, 2006, 2:44:28 AM, you wrote:

...

Maybe, but what is still unclear for me: Haskell is wrong for GUI/Database application because of lack of good libraries or because of it's way of programming???

primarily, first. to some degree, second too. Haskell doesn't provide such elegant representation of imperative algorithms as imperative languages does. just for example, counting sum [1..n]:

I see that "n" is not in an IORef, and for n=1 your loop leaves sum holding 0, which is just the kind of off-by-1 fencepost but that c excels in generating:

sum <- newIORef 0 i <- newIORef 1 let go = do i' <- readIORef i when (i'

compare this to C code :) of course, you can define a lot of sugar/combinators that simplify such code but anyway C will be better in this area

c code: int sum(int n) { int i = 1; int result = 0 for (; i<=n ; ++i) { result += i; } return result; } haskell: You really want this to be strict, so replace modifyIORef with modifyIORef'

modifyIORef' r f = do new <- liftM f (readIORef r) writeIORef r $! new return new

s1 n = do sum <- newIORef 0 forM_ [1..n] $ \i -> modifyIORef' sum (+i) readIORef sum

As you mentioned, there is easy syntactic sugar definable in Haskell itself:

a .+=. b = do new <- liftM2 (+) (readIORef a) (readIORef b) writeIORef a $! new

a .<=. b = liftM2 (<=) (readIORef a) (readIORef b)

succ_ i = modifyIORef' i succ

for init test inc block = do init let loop = do proceed <- test when proceed (block >> inc >> loop) loop

With that sugar it becomes easy to look very much like the c-code:

s2 n = do sum <- newIORef 0 i <- newIORef 1 for (return ()) (i .<=. n) (succ_ i) (sum .+=. i) readIORef sum

And we do have "postfix" operators with the latest GHC:

(.++) a = do old <- readIORef a writeIORef a $! succ old return old

On Sat, 2006-12-16 at 20:41 +0000, Neil Mitchell wrote:

That said, if I was writing a GUI+database thing, which doesn't do a lot of substantial processing (more just Add/Edit/Delete buttons), I'd definately use C# over Haskell.

Oh great... Duncan wrote: "That's certainly one of the use cases that we're aiming for in the Gtk2Hs project with our new api for the list/tree widget system. We can now more easily implement the data model in Haskell so the obvious thing to try would be a model based on a DB query." Although I'd be happy having available database-related widgets from gnomedb available as part of gtk2hs bindings, still I'm confident that above mentioned gtk2hs approach + eg. hdbc will be sufficient. I'll also need database capabilities for my application and plan to use sqlite as embedded engine, but having need for lot of calculations, I do not want to lose Haskell purity & elegant style at any cost ;)

Haskell can do this, but you are walking a relatively new path.

Someone has to pave the path, otherwise Haskell will eternally stay niche language, or we should adjust the motto on haskell.org where it is proudly stated: "Haskell is a general purpose, purely functional programming language." into something more appropriate :-) Sincerely, Gour