The discussion has focused so far somewhat on implementation routes. 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 If this were possible, then one could reduce effort in step (C) by using a toolkit (e.g. Gtk) that is already ported to multiple architectures, at the cost of look-and-feel; or, one could maintain look-and-feel compatibility by investing more in (C), so that the mapping was more native-aware. Regardless of which approach an implementor took, the application writer would still use interface (A). 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)". 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 That would be even better, because then lots of the implementation of (A) becomes shared between many targets. The Clean experience is that the code sharing is substantial. So I ask: 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? Simon