[GUI] Re: Gtk and Object I/O

[Simon Peyton-Jones]

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