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

[Achim Schneider]

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.