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

[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."

Thanks for joining in.

    - Conal


On Mon, Jan 26, 2009 at 3:05 PM, Achim Schneider <barsoap at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090129/5927261a/attachment.htm