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.
>----- Oorspronkelijk bericht -----
>Van: Donn Cave [mailto:[email protected]]
>Verzonden: woensdag, augustus 8, 2007 08:56 PM
>Aan: [email protected]
>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, [email protected]
>(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 mailing list