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%3AmakeNewGOb... [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.