
As a newbie (okay I will not write this again, you all know I'm a newbie by now ;-), I don't understood what the problem of a pure functional GUI is. To me, having an imperative background, a graphical application is just a big tree of data that evolves when events from the OS come in. (this data is NOT per se the data for the GUI element; instead use the model-view-controller design pattern) In Haskell, instead of mutating the data (as done in C/C++), a infinite stream of this tree-data is generated responding to an infinite steam of events, as in Paul's SOE book (the reactive stuff). Since most of the data can be shared, the performance impact should be minimal. So could you please tell me more about the problem with pure functional GUIs and why this is not part of the Haskell library? I mean a GUI library completely written in Haskell, not wrapping a popular library. Thanks, Peter
----- Oorspronkelijk bericht ----- Van: Donn Cave [mailto:donn@drizzle.com] Verzonden: woensdag, augustus 8, 2007 08:56 PM Aan: haskell-cafe@haskell.org Onderwerp: Re: [Haskell-cafe] a regressive view of support for imperative programming in Haskell
On Wed, 8 Aug 2007, Paul Hudak wrote: ...
Well, you could argue, monad syntax is what really made Haskell become more accepted by the masses, and you may be right (although perhaps Simon's extraordinary performance at OSCOM is more of what we need). On the other hand, if we give imperative programmers the tools to do all the things they are used to doing in C++, then we will be depriving them of the joys of programming in the Functional Way. How many times have we seen responses to newbie posts along the lines of, "That's how you'd do it in C++, but in Haskell here's a better way...".
It seems to me that Brian Hulley threw the glove down hard. Does pure functional Haskell offer a better way to write a GUI?
I love the functional stuff myself, but if real applications depend on extensive imperative logic, we're best served by a language that cheerfully embraces the inevitable and handles it well. Monads, the do syntax, whatever it takes (I have a soft spot for O'Haskell, but alas I must be nearly alone on that.) Hopefully, it's still better, and not at all irreconcilable with the Functional Way.
Donn Cave, donn@drizzle.com
(That's a genuine question, by the way - my attempt to build a current Haskell GUI library on NetBSD foundered and I have no experience with Haskell GUI coding, but it's on the list of things I would like to look at. So if there's one that really illustrates the virtues of pure functional Haskell programming, that would be a welcome tip!)
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe