This is the right approach to a GUI toolkit. Note that personally, I believe the details of the presentation should be separate from Haskell, stored in a separate file that is machine- friendly, so designers can work in concert and in parallel with developers. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Oct 6, 2009, at 10:22 AM, Andrew U. Frank wrote:

thanks for the connection to the gui runner - it is interesting and worthwile, but a different approach. my approach is strictly declarative and does not describe sequences of process. it describes screens and links operations to buttons. then it takes inputs from the screen and runs the operations and posts the result on the screen. some operations open new screens etc.

i started with the idea that ontologies describe the semantics of data in a static way; this should be (nearly) enough to create the user interface - which is all about semantics of the data. of course, you have to include in the ontology the semantics of the operations (as class with functions).

the implementation is close to a reactive framework - adding a representation of all what is visible on the screen (the universer of discourse) in a format usable by the operations. then you have only to connect this 'universe of discourse' to the programs which operate on the data and post their reaction in the UoD and map the UoD to the screen

the details are messy as i attempted to construct the internal data structures etc. as automatically as possible and with minimal designer input

I did not use template haskell, yet, but will need to (i think).

i am happy to share it with interested parties and hear the comments and perhaps somebody can help me with using templates to reduce the . it is IMHO not yet ready for posting in a library - but this is certainly the goal. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe