[Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense

[Conal Elliott]

On Mon, Feb 2, 2009 at 11:39 AM, Creighton Hogg <wchogg at gmail.com> wrote:

> 2009/1/29 Conal Elliott <conal at 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
Interfaces<http://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/f96a040f/attachment.htm