Re: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense
You know, I read the Fudgets thesis, and threw together an experiment which used Glade for layout and Haskell for semantics [1]. As somebody else noted, this isn't really a clean division, because of things like editable flags in the layout. The darcs repository has a couple of demo applications, there's also a Bridge game that doesn't quite work (not included), and I understand that Arrows would solve all my problems, but I still don't grok them, alas. What I found was that wiring the events through the application in a nice, functional way was quite tricky, but it was unclear whether this was just an API problem, or something more fundamental. The entire state seems to turn up in every connection between widgets (which really suggests that it's imperative with a veneer of declarative style, which of course it is). For example, you need a changed flag in the state of the text editor. This is updated by a signal from the text widget, and read by the main window (because it affects the title bar text), the File/New and File/Open menu items (need to put up a Save Changes? message box) and the main window destroy handler (same thing, but it also needs some way of cancelling the action). Unfortunately, the main window is at one end of the event chain, while the menu is all the way over on the other side. This leads to tricky composition, and widgets which pass the entire state to each other because there's one little bit of information they might need. A related issue is that the application is like a river, in which events flow from one end to the other. Send events back the other way is ugly. Some sort of blackboard design might work better. This conversation made me start thinking about replacing Glade with a Haskell layout language, but I still don't know how to solve the above problems. I should read the FRP papers again. cheers, Fraser. [1] http://thewhitelion.org/darcs/barrie On Mon, Feb 2, 2009 at 8:58 PM, John A. De Goes j...@n-brain.net wrote: The actual presentation and layout of widgets would be better handled by a DSL such as CSS (which is, in fact, declarative in nature), while event logic would be best handled purely in Haskell. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote: 2009/1/29 Conal Elliott co...@conal.net: Hi Achim, I came to the same conclusion: I want to sweep aside these OO, imperative toolkits, and replace them with something genuinely functional, which for me means having a precise simple compositional (denotational) semantics. Something meaningful, formally tractable, and powefully compositional from the ground up. As long as we build on complex legacy libraries (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse yet, drawn into) their ad hoc mental models and system designs. As Meister Eckhart said, Only the hand that erases can write the true thing. I think working on a purely functional widget toolkit would actually be a really cool project. Do you have any ideas, though, on what should be the underlying primitives? The initial gut feeling I have is that one should just ignore any notion of actually displaying widgets instead focus on a clean algebra of how to 'add' widgets that relates the concepts of inheritance relative position. What I mean by inheritance, here, is how to direct a flow of 'events'. I don't necessarily mean events in the Reactive sense, because I think it'd be important to make the model completely independent of how time actual UI actions are handled. Any thoughts to throw in, here? Cheers, C ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- http://thewhitelion.org/mysister ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense
2009/1/29 Conal Elliott co...@conal.net: Hi Achim, I came to the same conclusion: I want to sweep aside these OO, imperative toolkits, and replace them with something genuinely functional, which for me means having a precise simple compositional (denotational) semantics. Something meaningful, formally tractable, and powefully compositional from the ground up. As long as we build on complex legacy libraries (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse yet, drawn into) their ad hoc mental models and system designs. As Meister Eckhart said, Only the hand that erases can write the true thing. I think working on a purely functional widget toolkit would actually be a really cool project. Do you have any ideas, though, on what should be the underlying primitives? The initial gut feeling I have is that one should just ignore any notion of actually displaying widgets instead focus on a clean algebra of how to 'add' widgets that relates the concepts of inheritance relative position. What I mean by inheritance, here, is how to direct a flow of 'events'. I don't necessarily mean events in the Reactive sense, because I think it'd be important to make the model completely independent of how time actual UI actions are handled. Any thoughts to throw in, here? Cheers, C ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense
The actual presentation and layout of widgets would be better handled by a DSL such as CSS (which is, in fact, declarative in nature), while event logic would be best handled purely in Haskell. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote: 2009/1/29 Conal Elliott co...@conal.net: Hi Achim, I came to the same conclusion: I want to sweep aside these OO, imperative toolkits, and replace them with something genuinely functional, which for me means having a precise simple compositional (denotational) semantics. Something meaningful, formally tractable, and powefully compositional from the ground up. As long as we build on complex legacy libraries (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse yet, drawn into) their ad hoc mental models and system designs. As Meister Eckhart said, Only the hand that erases can write the true thing. I think working on a purely functional widget toolkit would actually be a really cool project. Do you have any ideas, though, on what should be the underlying primitives? The initial gut feeling I have is that one should just ignore any notion of actually displaying widgets instead focus on a clean algebra of how to 'add' widgets that relates the concepts of inheritance relative position. What I mean by inheritance, here, is how to direct a flow of 'events'. I don't necessarily mean events in the Reactive sense, because I think it'd be important to make the model completely independent of how time actual UI actions are handled. Any thoughts to throw in, here? Cheers, C ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense
Could CSS give us semantic clarity? - Conal On Mon, Feb 2, 2009 at 11:58 AM, John A. De Goes j...@n-brain.net wrote: The actual presentation and layout of widgets would be better handled by a DSL such as CSS (which is, in fact, declarative in nature), while event logic would be best handled purely in Haskell. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote: 2009/1/29 Conal Elliott co...@conal.net: Hi Achim, I came to the same conclusion: I want to sweep aside these OO, imperative toolkits, and replace them with something genuinely functional, which for me means having a precise simple compositional (denotational) semantics. Something meaningful, formally tractable, and powefully compositional from the ground up. As long as we build on complex legacy libraries (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse yet, drawn into) their ad hoc mental models and system designs. As Meister Eckhart said, Only the hand that erases can write the true thing. I think working on a purely functional widget toolkit would actually be a really cool project. Do you have any ideas, though, on what should be the underlying primitives? The initial gut feeling I have is that one should just ignore any notion of actually displaying widgets instead focus on a clean algebra of how to 'add' widgets that relates the concepts of inheritance relative position. What I mean by inheritance, here, is how to direct a flow of 'events'. I don't necessarily mean events in the Reactive sense, because I think it'd be important to make the model completely independent of how time actual UI actions are handled. Any thoughts to throw in, here? Cheers, C ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense
On Mon, Feb 2, 2009 at 11:39 AM, Creighton Hogg wch...@gmail.com wrote: 2009/1/29 Conal Elliott co...@conal.net: Hi Achim, I came to the same conclusion: I want to sweep aside these OO, imperative toolkits, and replace them with something genuinely functional, which for me means having a precise simple compositional (denotational) semantics. Something meaningful, formally tractable, and powefully compositional from the ground up. As long as we build on complex legacy libraries (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse yet, drawn into) their ad hoc mental models and system designs. As Meister Eckhart said, Only the hand that erases can write the true thing. I think working on a purely functional widget toolkit would actually be a really cool project. Do you have any ideas, though, on what should be the underlying primitives? Again, my goal would not be a purely functional library, because even IO is purely functional. My goal is a denotational library, i.e., one that has an elegant (denotational) semantics, and hence is powerfully compositional and good for reasoning. The initial gut feeling I have is that one should just ignore any notion of actually displaying widgets instead focus on a clean algebra of how to 'add' widgets that relates the concepts of inheritance relative position. What I mean by inheritance, here, is how to direct a flow of 'events'. I don't necessarily mean events in the Reactive sense, because I think it'd be important to make the model completely independent of how time actual UI actions are handled. Any thoughts to throw in, here? Cheers, C The Fruit paper, Genuinely Functional User Interfaceshttp://www.apocalypse.org/pub/u/antony/work/pubs/genuinely-functional-guis.pdf, gives a semantic model, which could be a starting place for thinking about possibilities. At the very least, I'd like to take it to 3D. The idea there is that a UI is a function from flows (behaviors/signals) to flows, where the input includes mouse keyboard stuff and the output includes an image. An image is, as in Pan, a function from R^2 - Color, where color includes partial opacity. When UIs are transformed in time and/or space, they correspondingly see inversely-transformed input, thanks to a general principle of transforming functions. - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense
The size, color, and layout of widgets has no effect on interaction semantics and is best pushed elsewhere, into a designer-friendly realm such as CSS. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 2, 2009, at 2:15 PM, Conal Elliott wrote: Could CSS give us semantic clarity? - Conal On Mon, Feb 2, 2009 at 11:58 AM, John A. De Goes j...@n-brain.net wrote: The actual presentation and layout of widgets would be better handled by a DSL such as CSS (which is, in fact, declarative in nature), while event logic would be best handled purely in Haskell. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote: 2009/1/29 Conal Elliott co...@conal.net: Hi Achim, I came to the same conclusion: I want to sweep aside these OO, imperative toolkits, and replace them with something genuinely functional, which for me means having a precise simple compositional (denotational) semantics. Something meaningful, formally tractable, and powefully compositional from the ground up. As long as we build on complex legacy libraries (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse yet, drawn into) their ad hoc mental models and system designs. As Meister Eckhart said, Only the hand that erases can write the true thing. I think working on a purely functional widget toolkit would actually be a really cool project. Do you have any ideas, though, on what should be the underlying primitives? The initial gut feeling I have is that one should just ignore any notion of actually displaying widgets instead focus on a clean algebra of how to 'add' widgets that relates the concepts of inheritance relative position. What I mean by inheritance, here, is how to direct a flow of 'events'. I don't necessarily mean events in the Reactive sense, because I think it'd be important to make the model completely independent of how time actual UI actions are handled. Any thoughts to throw in, here? Cheers, C ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense
On Mon, 2009-02-02 at 13:28 -0800, Conal Elliott wrote: On Mon, Feb 2, 2009 at 11:39 AM, Creighton Hogg wch...@gmail.com wrote: 2009/1/29 Conal Elliott co...@conal.net: Hi Achim, I came to the same conclusion: I want to sweep aside these OO, imperative toolkits, and replace them with something genuinely functional, which for me means having a precise simple compositional (denotational) semantics. Something meaningful, formally tractable, and powefully compositional from the ground up. As long as we build on complex legacy libraries (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse yet, drawn into) their ad hoc mental models and system designs. As Meister Eckhart said, Only the hand that erases can write the true thing. I think working on a purely functional widget toolkit would actually be a really cool project. Do you have any ideas, though, on what should be the underlying primitives? Again, my goal would not be a purely functional library, because even IO is purely functional. My goal is a denotational library, i.e., one that has an elegant (denotational) semantics, and hence is powerfully compositional and good for reasoning. +1 jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense
On Mon, Feb 2, 2009 at 3:28 PM, Conal Elliott co...@conal.net wrote: On Mon, Feb 2, 2009 at 11:39 AM, Creighton Hogg wch...@gmail.com wrote: snip I think working on a purely functional widget toolkit would actually be a really cool project. Do you have any ideas, though, on what should be the underlying primitives? Again, my goal would not be a purely functional library, because even IO is purely functional. My goal is a denotational library, i.e., one that has an elegant (denotational) semantics, and hence is powerfully compositional and good for reasoning. Well, that is essentially what I meant but your point about clarity is taken. A truly mathematical semantic model is above beyond what is meant by purely functional. The initial gut feeling I have is that one should just ignore any notion of actually displaying widgets instead focus on a clean algebra of how to 'add' widgets that relates the concepts of inheritance relative position. What I mean by inheritance, here, is how to direct a flow of 'events'. I don't necessarily mean events in the Reactive sense, because I think it'd be important to make the model completely independent of how time actual UI actions are handled. Any thoughts to throw in, here? Cheers, C The Fruit paper, Genuinely Functional User Interfaces, gives a semantic model, which could be a starting place for thinking about possibilities. At the very least, I'd like to take it to 3D. The idea there is that a UI is a function from flows (behaviors/signals) to flows, where the input includes mouse keyboard stuff and the output includes an image. An image is, as in Pan, a function from R^2 - Color, where color includes partial opacity. When UIs are transformed in time and/or space, they correspondingly see inversely-transformed input, thanks to a general principle of transforming functions. Thanks. I'm reading it now. Cheers, C ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense
Well, that is also the idea behind Microsoft's WPF/XAML: they provide a declarative approach to describe the widget tree (specifying what it is, not what is does), and a GUI toolkit (Expression Blend) for artists and designers so they can use a high level tool to build the GUI. You can even define limited behavior and animation in a declarative way. However, I believe those designer friendly tools are not designed by designers but by programmers who claim to think what designers want. I work everyday with artists and designers, and these people are frustrated by the limitations and erratic behavior (read side effects) of most designer friendly tools... Furthermore making even a simple GUI requires a lot of collaboration between the developer and the designer, and this screams for a language that both can understand and reason about :-) Also, this approach is nice for simple or (should I say mostly form-based GUIs), but as soon as you get into something more complicated, this design won't help you. For example, try to make a mathematical editor like that... or a diagram editor... IMO any GUI framework should work for complicated GUIs as well as easy form based one. I feel the model - presentation - view - reactivity - model' cycle is still the best approach today for building complex GUIs. Never start with widgets, these are just a possible representation of a model. Although this paradigm comes from Smalltalk, MVC is really functional in my opinion.. If you make that approach compositional *and* fast, you have a winner. Something like FRUIT on steroids (Grapefruit? ;-) but then of course you are stuck with the arrows syntax which feels like drawing graphical circuits with a text editor ;-) 2009/2/2 John A. De Goes j...@n-brain.net The size, color, and layout of widgets has no effect on interaction semantics and is best pushed elsewhere, into a designer-friendly realm such as CSS. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 2, 2009, at 2:15 PM, Conal Elliott wrote: Could CSS give us semantic clarity? - Conal On Mon, Feb 2, 2009 at 11:58 AM, John A. De Goes j...@n-brain.net wrote: The actual presentation and layout of widgets would be better handled by a DSL such as CSS (which is, in fact, declarative in nature), while event logic would be best handled purely in Haskell. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote: 2009/1/29 Conal Elliott co...@conal.net: Hi Achim, I came to the same conclusion: I want to sweep aside these OO, imperative toolkits, and replace them with something genuinely functional, which for me means having a precise simple compositional (denotational) semantics. Something meaningful, formally tractable, and powefully compositional from the ground up. As long as we build on complex legacy libraries (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse yet, drawn into) their ad hoc mental models and system designs. As Meister Eckhart said, Only the hand that erases can write the true thing. I think working on a purely functional widget toolkit would actually be a really cool project. Do you have any ideas, though, on what should be the underlying primitives? The initial gut feeling I have is that one should just ignore any notion of actually displaying widgets instead focus on a clean algebra of how to 'add' widgets that relates the concepts of inheritance relative position. What I mean by inheritance, here, is how to direct a flow of 'events'. I don't necessarily mean events in the Reactive sense, because I think it'd be important to make the model completely independent of how time actual UI actions are handled. Any thoughts to throw in, here? Cheers, C ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense
Hi John, I'm not sure how to interpret your remarks about has no effect and is best. I guess they're subjective opinions, but maybe I'm missing something objective in your intent. I can see, for instance, at least one way in which layout has a direct and enormous effect on interaction semantics. And while I can see some benefits in choosing CSS, I also see some significant drawbacks, and I wonder if you've factored these drawbacks into your is best. - Conal 2009/2/2 John A. De Goes j...@n-brain.net The size, color, and layout of widgets has no effect on interaction semantics and is best pushed elsewhere, into a designer-friendly realm such as CSS. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 2, 2009, at 2:15 PM, Conal Elliott wrote: Could CSS give us semantic clarity? - Conal On Mon, Feb 2, 2009 at 11:58 AM, John A. De Goes j...@n-brain.net wrote: The actual presentation and layout of widgets would be better handled by a DSL such as CSS (which is, in fact, declarative in nature), while event logic would be best handled purely in Haskell. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote: 2009/1/29 Conal Elliott co...@conal.net: Hi Achim, I came to the same conclusion: I want to sweep aside these OO, imperative toolkits, and replace them with something genuinely functional, which for me means having a precise simple compositional (denotational) semantics. Something meaningful, formally tractable, and powefully compositional from the ground up. As long as we build on complex legacy libraries (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse yet, drawn into) their ad hoc mental models and system designs. As Meister Eckhart said, Only the hand that erases can write the true thing. I think working on a purely functional widget toolkit would actually be a really cool project. Do you have any ideas, though, on what should be the underlying primitives? The initial gut feeling I have is that one should just ignore any notion of actually displaying widgets instead focus on a clean algebra of how to 'add' widgets that relates the concepts of inheritance relative position. What I mean by inheritance, here, is how to direct a flow of 'events'. I don't necessarily mean events in the Reactive sense, because I think it'd be important to make the model completely independent of how time actual UI actions are handled. Any thoughts to throw in, here? Cheers, C ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense
How do you define layout in a way that has a direct an enormous effect on interaction semantics??? Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 2, 2009, at 4:31 PM, Conal Elliott wrote: Hi John, I'm not sure how to interpret your remarks about has no effect and is best. I guess they're subjective opinions, but maybe I'm missing something objective in your intent. I can see, for instance, at least one way in which layout has a direct and enormous effect on interaction semantics. And while I can see some benefits in choosing CSS, I also see some significant drawbacks, and I wonder if you've factored these drawbacks into your is best. - Conal 2009/2/2 John A. De Goes j...@n-brain.net The size, color, and layout of widgets has no effect on interaction semantics and is best pushed elsewhere, into a designer-friendly realm such as CSS. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 2, 2009, at 2:15 PM, Conal Elliott wrote: Could CSS give us semantic clarity? - Conal On Mon, Feb 2, 2009 at 11:58 AM, John A. De Goes j...@n-brain.net wrote: The actual presentation and layout of widgets would be better handled by a DSL such as CSS (which is, in fact, declarative in nature), while event logic would be best handled purely in Haskell. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote: 2009/1/29 Conal Elliott co...@conal.net: Hi Achim, I came to the same conclusion: I want to sweep aside these OO, imperative toolkits, and replace them with something genuinely functional, which for me means having a precise simple compositional (denotational) semantics. Something meaningful, formally tractable, and powefully compositional from the ground up. As long as we build on complex legacy libraries (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse yet, drawn into) their ad hoc mental models and system designs. As Meister Eckhart said, Only the hand that erases can write the true thing. I think working on a purely functional widget toolkit would actually be a really cool project. Do you have any ideas, though, on what should be the underlying primitives? The initial gut feeling I have is that one should just ignore any notion of actually displaying widgets instead focus on a clean algebra of how to 'add' widgets that relates the concepts of inheritance relative position. What I mean by inheritance, here, is how to direct a flow of 'events'. I don't necessarily mean events in the Reactive sense, because I think it'd be important to make the model completely independent of how time actual UI actions are handled. Any thoughts to throw in, here? Cheers, C ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense
Hi Achim, I came to the same conclusion: I want to sweep aside these OO, imperative toolkits, and replace them with something genuinely functional, which for me means having a precise simple compositional (denotational) semantics. Something meaningful, formally tractable, and powefully compositional from the ground up. As long as we build on complex legacy libraries (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse yet, drawn into) their ad hoc mental models and system designs. As Meister Eckhart said, Only the hand that erases can write the true thing. Thanks for joining in. - Conal On Mon, Jan 26, 2009 at 3:05 PM, Achim Schneider bars...@web.de wrote: Hacking away on bindings to (http://libagar.org), specifically (http://libagar.org/mdoc.cgi?man=AG_Object.3), I was suddenly swept away by a general crisis of purpose: I was spending time on figuring out how to create agar objects, implemented in Haskell, on the fly, to enable me to write a high-level interface, instead of spending time on designing The FRUI API To Obsolete Them All. The reason for this are means of composability: What use is a nice interface to a button and an isomorphic interface to a textbox, if I can't compose them properly? Users might want to use standard widgets in indefinitely many combinations of type, with an equal amount of distinct wirings and external interfaces. As some of you might have noticed [1][2], constructing foreign objects is painful, specifying custom classes even more so... in case it's not infeasible hard to support in the first place. In agar's case it's certainly possible, by the virtue of being implemented in plain C. So we _could_ expose the whole generality of a TK's means of composing to the user. Which is most likely not what he wants, he wants to use the whole generality of Haskell to compose UI's. In Agar's case, the user won't care much about generating N checkboxes for a bitfield integer, he'd rather use [Event Bool]. Summing up, there's a lot of plumbing to be done, in the end still amounting to a lot of dead, unused code in the TK, BECAUSE TOOLKITS ARE DESIGNED TO BE USED IN THE LANGUAGE THEY WERE BLEEDING WRITTEN IN AND PROVIDE CUSTOM ABSTRACTIONS TAILORED TO THAT LANGUAGE. This is basically the Saphir-Worph hypothesis adapted to programs. So what's left of those TK's if we don't use their abstractions and replace them with Haskell? Drawing and layouting, that's what's left[3]. Both, IMNSHO, do not justify carrying around bloaty external dependencies, they're too trivial. They certainly don't justify using unsafePerformIO to hide foreign side effects and the headaches associated with it. So, if you don't mind, I'm going to stop trying to fit cubes into round holes and gonna use reactive and fieldtrip[4] to do things. [1]http://softbase.org/hqk/qoo/qoo.pdf [2] http://haskell.org/gtk2hs/docs/devel/System-Glib-GObject.html#v%3AmakeNewGObject [3]Somewhat disregarding using OS widgets, but that's unimportant since native look+feel is vastly overrated. I've got enough asbestos to defend that against alt.politics. [4]Gotta get rid of glut, though. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense
So, if you don't mind, I'm going to stop trying to fit cubes into round holes and gonna use reactive and fieldtrip[4] to do things. Yes exactly, these projects are an attempt to make reactive programming (and GUI programming is one of these) much more composable. However it is still unclear to me if these frameworks can fix the typical space leaks that have been addressed in AFRP (e.g. Yampa) and also mentioned in the Fruit paper. A nice discussion between Yampa and Reactive took place in this list a while ago (see http://www.nabble.com/Yampa-vs.-Reactive-td21045891.html)http://www.nabble.com/Yampa-vs.-Reactive-td21045891.html So AFRP also tries to make reactive programming more composable, and already succeeded somehow by showing working games and prototype guis, but the arrows syntax takes away much of the elegance of Haskell (we're really drawing boxes and links in Haskell here ;-) and research is still being done to make it more scalable (push versus pull, see e.g. http://www.cs.yale.edu/homes/hl293/download/NEPLS-talk.pdf)http://www.cs.yale.edu/homes/hl293/download/NEPLS-talk.pdf To me, none of these approaches mean anything as long as we can't produce real complex GUIs with it :-) I do hope that Haskell community will combine efforts to make a practical reactive (and GUI) framework! [1]http://softbase.org/hqk/qoo/qoo.pdf [2] http://haskell.org/gtk2hs/docs/devel/System-Glib-GObject.html#v%3AmakeNewGObject [3]Somewhat disregarding using OS widgets, but that's unimportant since native look+feel is vastly overrated. I've got enough asbestos to defend that against alt.politics. [4]Gotta get rid of glut, though. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense
Hacking away on bindings to (http://libagar.org), specifically (http://libagar.org/mdoc.cgi?man=AG_Object.3), I was suddenly swept away by a general crisis of purpose: I was spending time on figuring out how to create agar objects, implemented in Haskell, on the fly, to enable me to write a high-level interface, instead of spending time on designing The FRUI API To Obsolete Them All. The reason for this are means of composability: What use is a nice interface to a button and an isomorphic interface to a textbox, if I can't compose them properly? Users might want to use standard widgets in indefinitely many combinations of type, with an equal amount of distinct wirings and external interfaces. As some of you might have noticed [1][2], constructing foreign objects is painful, specifying custom classes even more so... in case it's not infeasible hard to support in the first place. In agar's case it's certainly possible, by the virtue of being implemented in plain C. So we _could_ expose the whole generality of a TK's means of composing to the user. Which is most likely not what he wants, he wants to use the whole generality of Haskell to compose UI's. In Agar's case, the user won't care much about generating N checkboxes for a bitfield integer, he'd rather use [Event Bool]. Summing up, there's a lot of plumbing to be done, in the end still amounting to a lot of dead, unused code in the TK, BECAUSE TOOLKITS ARE DESIGNED TO BE USED IN THE LANGUAGE THEY WERE BLEEDING WRITTEN IN AND PROVIDE CUSTOM ABSTRACTIONS TAILORED TO THAT LANGUAGE. This is basically the Saphir-Worph hypothesis adapted to programs. So what's left of those TK's if we don't use their abstractions and replace them with Haskell? Drawing and layouting, that's what's left[3]. Both, IMNSHO, do not justify carrying around bloaty external dependencies, they're too trivial. They certainly don't justify using unsafePerformIO to hide foreign side effects and the headaches associated with it. So, if you don't mind, I'm going to stop trying to fit cubes into round holes and gonna use reactive and fieldtrip[4] to do things. [1]http://softbase.org/hqk/qoo/qoo.pdf [2]http://haskell.org/gtk2hs/docs/devel/System-Glib-GObject.html#v%3AmakeNewGObject [3]Somewhat disregarding using OS widgets, but that's unimportant since native look+feel is vastly overrated. I've got enough asbestos to defend that against alt.politics. [4]Gotta get rid of glut, though. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
