Simon, On Fri, Jan 24, 2003 at 01:11:02PM -0000, Simon Peyton-Jones wrote: [..]
My hope is that
(A) we can define programming interface (i.e. a collection of abstract types and functions)
(B) that is rich enough to be useful for writing GUI applications
(C) and yet can be mapped onto a variety of architectures and toolkits
[..]
The question is: what should (A) look like? Is it even possible to define a rich enough (A) without making (C) impossible? The answer to the latter question must surely be "yes, provided one is not too ambitious with (A)".
You mean "ambitious with (B)", I assume. Again, reducing (B) automatically means affecting the look-and-feel. But for me this is not a severe issue.
Peter Aachten goes further. Based on the Clean group's experience, he thinks we can not only define a satisfactory (A), but also define a lower-level interface (expressed in the C language) that suffices to support (A) and yet contains no target specific code No target specific code? I don't think I understand what you mean. The APIs are target specific. So where is the advantage of specifying the impedance matching code in C?
what are the candidates for (A)?
I've suggested one: the Clean Object-IO model, or something related (the MVar vs local state question is still open). Are there any other proposals? I am happy with Object I/O concept as a medium layer. But I am very suspicious about the intermediate layer. You said you would go for a GUI interface which is reduced but portable and I fear that it is a very time consuming effort to find this layer. I believe that there are many people right now who want to write GUI applications who I think we should serve.
A proposal: We start from different platforms: - we have an Object I/O library for Win32 in ghc's CVS - Gtk - A native Aqua interface could be started Can we extract the core infrastructure (no widgets) of Object I/O into a separate CommonGUI module which all these libraries use. We could then gradually define widget (and other) abstractions in the CommonGUI library and map them to all native libraries. Advantages: - People who want to do full fledged applications can do so right now using one of the native libraries. - In the long run, we will have a CommonGUI library which restricts itself to elements which can be implemented with the native look-and-feel. Any comments? Axel.