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 wrote:

2009/1/29 Conal Elliott :

...

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.p...", 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