RE: [GUI] Proposal Proposal: haskell-gui addendum to haskell

| Perhaps the best would be to use an Object-IO like interface | with mvars as proposed by Simon Peyton-Jones, simply because it's | higher level than raw gui-calls and the Clean folks have used | it cross-platform in a few real apps. Indeed. My impression is that we won't get far trying to design a truly high-level declarative GUI toolkit, because there just isn't enough consensus on what it should look like. There have been a number of very interesting experiments, but none has captured everyone's attention. I just don't think we yet know the answer here, though I am hopeful that further exploration will eventually uncover it (or them). Meanwhile, lacking the Final Answer, we need a practical solution. One possibility would be to adopt some multi-platform toolkit like Gtk, and provide a Haskell wrapper for each function. Several such bindings exist. But that is (a) terribly low level, (b) very toolkit-specific. I think we can do a bit better. My personal favourite is the Clean Object-IO story: it's higher level and more abstract than just a simple imperative veneer over (eg) Gtk, but it's still low level enough that its not hard to implement. Furthermore, the Clean folk have a developed over a decade, so they have *lots* of experience of using it in real applications. Let's take advantage of their wisdom; I would be surprised if we could do better if we started from a blank sheet of paper. So I propose the Clean Object-IO approach as a reasonable compromise starting point for the programming interface. (I'm entirely agnostic about what is the most suitable underlying C library to use; indeed, the choice of that library should ideally be un-discoverable to the programmer.) I say "starting point" because there are still plenty of design choices to be made. For example, to use the Clean "local state" idea or use MVars? This choice is discussed in the paper that Peter Aachten and I wrote: http://research.microsoft.com/~simonpj/Papers/haskellobjectio.htm I'm sure there are many other choices. This suggestion is not based on deep study. Maybe others have better ideas. But I counsel against trying to find a truly high-level design. Worse is better. Simon

On Thu, 23 Jan 2003 10:22:44 -0000
"Simon Peyton-Jones"
So I propose the Clean Object-IO approach as a reasonable compromise starting point for the programming interface. (I'm entirely agnostic about what is the most suitable underlying C library to use; indeed, the choice of that library should ideally be un-discoverable to the programmer.)
Maybe this is the good way; in this case, the best thing to my eyes is NOT to use any particular toolkit, but rather design the Object-IO in a way that it's implementable with gtk or gtk2 (which are already implemented) but opened to other bindings (I guess most people would like a native windows API implementation). And I suggest to keep particularities of the various systems in modules which carry "NonPortable" into their name, so we will be able to get a portable UI without throwing away anything that could be better on a single system. For the "high level" interface, I just hope that a mid-level library won't stop people from researching, and trying to develop and use, the high-level ones, because that would mean "a better language, but used in the traditional way". Maybe I am wrong. (hoping that someone will understand my messy english) Vincenzo -- Fedeli alla linea, anche quando non c'è Quando l'imperatore è malato, quando muore,o è dubbioso, o è perplesso. Fedeli alla linea la linea non c'è. [CCCP]
participants (2)
-
Nick Name
-
Simon Peyton-Jones