Wolfgang Jeltsch wrote:

Covering reactive programming would indeed be interesting.

I want to add that there is no single way for doing reactive programming in Haskell. There is Conal’s stuff, there is Yampa and there is “my” stuff (Grapefruit [1]) whereby the pros and cons of these approaches differ. (And there is plenty of other stuff which doesn’t seem to be actively developed, like, for example, FranTk.)

Doesn't that count for everything? I've been doing imperative & OO programming for more than 2 decades, and every technique has its pros and cons, it's what makes the job hard, picking the right choices, which is (in my case) often more a matter of taste and "it worked before" than good reasoning. It would be nice to just briefly introduce the reactive topic and available solutions, and let the user know what the advantages and disadvantages are of each approach, so he does not reinvent the wheel. It is a very interesting domain. Gtk2HS can hardly be called pure functional programming can it? It is IO and monads everywhere. Not that I have something against that (it works!), but IMHO it does not offer the same "combinatorial" (?) and declarative advantages of the reactive approach, does it? And isn't the fact that some of these reactive approaches "blow up" (space/time leaks) just a general consequence of Haskell's laziness? You get it more often with approaches like FRP, it works a bit better in AFRP (but you still have to be careful for leaks). So in imperative languages you get buffer overruns, null pointers, dangling pointers, overly eager evaluation, side effects depending on evaluation order, etc... In Haskell you can get space/time leaks caused by hard to track mutually recursive dependencies and unevaluated thunks (I guess). I had it with the former, so I'm happy to try the latter and see where it brings me... The more people get introduced to this reactive proggy, the better?

Also note that reactive programming in Haskell is not as mature as, for instance, GUI programming with Gtk2Hs. So it might not be wise to add a chapter on it now. Maybe in the second version of the book. :-)

Yes but it's not yet robust either. When I made some programs with Gtk2HS, I encountered a couple of bugs that I reported (bugs in the GTK code on Windows, so nothing to do with Haskell), so what is "mature"? I haven't looked at Grapefruit yet (actually I don't like fruit, but I like vegetables, so lucky me ;-). I will certainly do so. Any interesting links? Cheers, Peter

Wolfgang Jeltsch wrote:

Indeed. A functional approach to GUIs is nice but at the moment we don’t have anything that is suitable for solving real world problems (although this is being worked on). Could you elaborate a bit on that? What are the current obstacles to be solved?

When I looked at Yampa, I didn't really see a problem with making a GUI or interactive application based on it (besides maybe performance and space/time leaks, the latter IMO being a general problem in Haskell that just occurs quicker in reactive programming). I could model state machines, dynamic collections, events and event handlers with it, all hierarchically. I just would have to practice much much more to get good at it. Of course, I'm way too new to functional programming to really judge Yampa, it's just the feeling I got from it. The main problem I could see is that Yampa is not really event driven in the imperative sense; I mean in an ideal event based system, the hardware triggers an interrupt when some sensor changes, and this then triggers other software events; only the code that is related to handling the event that occurred is executed. But the event that is handled could potentially not be needed for the current output (which could be considered as a programming bug...) I think Yampa does not do that, it kinda "pulls" the information out of the current signal function network, which has the advantage of only executing the code that is needed for the output, but the disadvantage is that it does a lot of routing and checking which event happened. Warning to newbies: the above is most likely incorrect information, this is just the way I experienced it ;-) Now IMO the OO way of handling GUIs is also not carved in stone. OO and imperative programmers also seem to continue the search for "the best" GUI event system. For example, the first version of the .NET GUI "borrowed" the Delphi approach, which was a direct link (through a delegate in .NET, called closure in Delphi) between the event source and the event listener (in C we know that as a list of (callback,userdata) ;-) ). Same for QT's signal/slot system. Other systems use a producer/dispatcher/consumer pattern (or how is it called). Java AWT initially used a message based system, then switched to an interface based system. Other systems (like MFC) used a message based approach, where the message is routed to many components in a hierarchy. The latest version of .NET's GUI system (WPF) again uses such an "element tree" and the event can be routed through the whole tree in both directions. Some claim Smalltalk's model-view-controller is still the best pattern, others claim that the controller is too closely linked to the view to be really separate and stick to a document/view model, or just duplicate data by using some kind of data-binding... I tried all approaches over the last 20 years, and I still see no "best" way...

:-) The working name for Grapefruit was Vegetables, by the way. ;-) LOL! I'll certainly look at it, I find it very fascinating (though confusing...) to compare all existing reactive solutions

Thank you, Peter

Hello Peter, an answer to an “old” e-mail (from January 25). Sorry for not answering earlier. Am Freitag, 25. Januar 2008 00:23 schrieben Sie:

Wolfgang Jeltsch wrote:

...

Indeed. A functional approach to GUIs is nice but at the moment we don’t have anything that is suitable for solving real world problems (although this is being worked on).

Could you elaborate a bit on that? What are the current obstacles to be solved?

Performance problems and lack of widgets are the two things that come to my mind immediately. Maybe also lack of a good way of doing dynamic user interfaces (user interfaces with a changing set/order of widgets).

When I looked at Yampa, I didn't really see a problem with making a GUI or interactive application based on it (besides maybe performance and space/time leaks, the latter IMO being a general problem in Haskell that just occurs quicker in reactive programming).

I think, performance is a big problem. To me it seems that Yampa-based GUIs maybe have a performance penalty of more than just a constant factor. Please have a look at the sections “Implementation and efficiency” and “Signals” under http://haskell.org/haskellwiki/Talk:Grapefruit.

[…]

The main problem I could see is that Yampa is not really event driven in the imperative sense; I mean in an ideal event based system, the hardware triggers an interrupt when some sensor changes, and this then triggers other software events; only the code that is related to handling the event that occurred is executed. But the event that is handled could potentially not be needed for the current output (which could be considered as a programming bug...)

Not necessarily a bug. There are events which don’t result in changes of the GUI, for example, mouse clicks into empty areas.

[…]

Best wishes, Wolfgang

Am Donnerstag, 7. Februar 2008 18:33 schrieben Sie:

Interesting. Thanks for the reply.

It might be nice to have some performance benchmarks for all these experimental systems, so we can compare them.

I think, the most important thing is the asymptotical time behavior, e.g., whether the time of a certain task is linear, logarithmic or constant in the number of widgets. Constant factors can always be improved. So performance benchmarks don’t seem so important to me in the current early state of FRP GUI libraries.

I could understand that performance might be an issue for games, but for GUIs? I mean many imperative GUI systems use rather slow message dispatching systems, and we use those every day. Look at the new Windows Presentation Foundation system found in VISTA. Here events are broadcasted and routed through the whole element tree. This is also rather slow I guess.

Are they rooted through every node of the tree (linear time) or are they routed down the tree to a leaf (not more than logarithmic time, probably). The latter would be acceptable, the former not. The problem I noted on the Grapefruit talk page might result in a Yampa-based GUI taking linear time for handling a single event (but I’m not completely sure about that). Does Vista’s event handling really have linear behavior as your statement seems to suggest? Best wishes, Wolfgang

I think this points out the benefit (or even the need), given the fast-paced evolution of Haskell and its libraries as a whole, of an evolving online supplement to your book, minimally with errata and code, but also (as publisher resources permit) with intermittently updated appendices on still-evolving technologies and (most risky of all), advice on the best tool or library of various tasks (e.g. UI) as a function of risk and programmer experience. I think this approach is the surest defense against shelf-rot. Dan Bryan O'Sullivan wrote:

Wolfgang Jeltsch wrote:

...

Covering reactive programming would indeed be interesting.

I agree. However, we have no plans to cover this topic. I don't believe any of us has used FRP, and my impression of it as an approach is that it's not yet cooked. We already have our hands and TOC full covering well-established topics, never mind tracking the leading edge of research. (For similar reasons, we won't be writing about ndp, even though it's got a lot more obvious crowd appeal.)

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

Jon Harrop wrote:

On Tuesday 22 January 2008 14:30:22 Bryan O'Sullivan wrote:

...

Paul Moore wrote:

...

I'm posting here because there doesn't seem to be an "overall" comment section, but the TOC seems to cover less ground than I expected. Is the TOC meant to be complete?

No, it's less than a third of the whole thing.

Here's the announcement from last May, including a more detailed TOC: http://www.realworldhaskell.org/blog/2007/05/23/real-world-haskell-its-time

We've since added a few chapters...

Will there be a chapter on OpenGL?

Please, don't. With the current state of Haskell's openGL, all you need is the redbook and a sed command that removes the 3f from vertex3f. The most innovative feature that I witnessed is preservingMatrix <io code> instead of pushMatrix(); <io code>; popMatrix();, but then you could write a C macro to do exactly that. It's the same with glBegin() and glEnd(). So, please, please, don't. OTOH, all this vertex3f stuff and the difference between glBegin(GL_QUAD) and glBegin(GL_POLYGON) is in some way a nice example of expressing data using monadic composition. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited.