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 <john@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 <conal@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